6. Wenn etwas schiefgeht
7. Die Include-Dateien und Units von OptiVec
1. Einführung
OptiVec bietet eine umfangreiche Bibliothek zur effizienten und genauen Verarbeitung von Daten, die in ein- oder zweidimensionalen Arrays vorliegen. Das Konzept der "vektorisierten Programmierung" wird hiermit auf sehr einfache und übersichtliche Weise für die Sprachen C/C++ und Pascal/Delphi verfügbar gemacht. Der Ersatz konventioneller Schleifen durch Vektor- und Matrix-Funktionen führt zu einer starken Vereinfachung der Schreibarbeit des Programmierers und zu einem großen Gewinn an Geschwindigkeit und Genauigkeit der Programme.
Dem Ziel der Vereinfachung dienen zwar bereits seit mehr als zwei Jahrzehnten auch die Feldfunktionen von Fortran90 und templatisierte Vektor-Klassen in C++, doch sind dies lediglich Abkürzungen, die vom Compiler wieder in Schleifen übersetzt und entsprechend ineffizient verarbeitet werden. (Ähnliches gilt für die meisten der populären BLAS-Bibliotheken für Fortran). Demgegenüber bietet OptiVec eine hochoptimierte, in Assembler geschriebene Lösung, deren Geschwindigkeit nicht mehr durch die Qualität des Compilers, sondern nur noch durch die echte Geschwindigkeit des Prozessors bestimmt wird. Gegenüber compiliertem Code ergibt sich ein durchschnittlicher Geschwindigkeitsvorteil von einem Faktor 2 bis 3 (für einige Funktionen auch bis zu 8).
Nach unserem Kenntnisstand war OptiVec beim Erscheinen 1996 die erste umfassende Vektor- und Matrix-Bibliothek für PC-Compiler, die praktisch vollständig in Maschinensprache geschrieben wurde.
OptiVec tritt in Konkurrenz zu etlichen teuren integrierten Programmsystemen für wissenschaftliche und Datenverarbeitungs-Anwendungen, ist aber eben nicht ein "geschlossenes" integriertes Paket, sondern zur Verwendung mit den gängigen Programmiersprachen bestimmt, wodurch dem OptiVec-Benutzer die Flexibilität seiner bevorzugten Programmierumgebung erhalten bleibt.
Hier einige Stichworte:
- Alle Operatoren und mathematischen Funktionen von C/C++ und Pascal/Delphi sind in vektorisierter Form implementiert; zusätzlich sind viele weitere mathematische Funktionen aufgenommen, die sonst als mehr oder weniger komplizierte Kombination existierender Funktionen berechnet werden müßten. Ausführungsgeschwindigkeit und numerische Genauigkeit werden hierdurch stark verbessert.
- MatrixLib deckt einen großen Bereich optimierter Matrix-Funktionen ab: Arithmetik, Algebra, Faktorisierungen, Daten-Anpassungen usw.
TensorLib ist als spätere Erweiterung dieser Konzepte auf multidimensionale Felder geplant.
- Fast-Fourier-Transform-Techniken für effiziente Faltungen/Entfaltungen, Korrelations- und Spektralanalysen, Filterung etc. sind sowohl für ein- als auch zweidimensionale Felder enthalten.
- Es gibt zahlreiche Bausteine für statistische Analyse.
- Ableitungen, Integrale, Interpolationen werden durch die Analysis-Funktionen von VectorLib berechnet.
- Graphik-Funktionen für Plots in cartesischen Koordinaten erlauben die Darstellung von Vektor- und Matrix-Daten.
- Alle Funktionen haben eine übersichtliche, intuitiv verständliche und einfache Syntax.
- Jede Funktion existiert für jeden Daten-Typ, für den dies sinnvoll ist, also meist für alle Ganzzahl-Typen, alle reellen und häufig auch komplexen Fließkomma-Typen. Der Datentyp wird einfach durch das Präfix des Funktionsnamens bestimmt. In der C/C++-Version werden keine impliziten Namensergänzungen ("name mangling") oder andere spezifische Eigenschaften von C++ verwandt. Dadurch kann OptiVec in C ebenso wie in C++ benutzt werden, und dadurch wird gewährleistet, daß Funktionsnamen und -syntax in den OptiVec-Versionen für C/C++ und Pascal/Delphi weitestgehend identisch sind.
- Die Eingabe- und Ausgabe-Vektoren und -Matrizen von OptiVec-Funktionen sind von variabler Größe, und es ist möglich, auch nur einen Teil (z.B. die ersten 100 Elemente, jedes 10. Element usw.) eines Vektors zu verarbeiten – ein weiterer Vorteil gegenüber anderen Ansätzen, bei denen nur ganze Felder verarbeitet werden können.
- Ein objekt-orientiertes Interface für C++, VecObj kapselt alle Vektorfunktionen und bietet noch einfachere Syntax sowie verbesserte Sicherheit der Speicherzugriffe.
- Der Einsatz von OptiVec-Funktionen anstatt Schleifen erlaubt es, Quellcode viel kompakter und lesbarer zu gestalten.
- Zusätzlich zu den komplexen Vektor- und Matrix-Routinen bietet CMATH eine Bibliothek Funktionen für skalare komplexe Zahlen aller drei Fließkomma-Genauigkeiten, sowohl in cartesischen als auch in Polarkoordinaten. Im Vergleich zu anderen erhältlichen komplexen Klassenbibliotheken sowie der Unit Complex von Delphi ist CMATH durch seine Implementierung in Assembler wesentlich schneller, genauer und stabiler. Außerdem benötigt die C/C++-Version nicht unbedingt C++, sondern kann auch in klassischen C-Modulen verwendet werden (dann mit typenspezifischen Funktions-Präfixen).
Der große Funktions-Umfang, die hohe numerische Genauigkeit und die Einfachkeit der Benutzung machen OptiVec zu einem wertvollen Programmierwerkzeug für wissenschaftlich-technische Datenverarbeitungs-Anwendungen.
1.1 Warum sich vektorisierte Programmierung auf dem PC lohnt
Um eindimensionale Datenfelder oder "Vektoren" zu verarbeiten, schreibt der Programmierer normalerweise eine Schleife über alle Vektor-Elemente. Und zwei- oder höher-dimensionale Felder ("Matrizen" oder "Tensoren") werden üblicherweise mittels verschachtelter Schleifen über die Indizes in allen Dimensionen verarbeitet. Die Alternative zu diesem klassischen Programmier-Stil sind Vektor- und Matrix-Funktionen.
Vektor-Funktionen wirken auf ganze Vektoren anstatt einzelne skalare Argumente. Sie stellen die konsequenteste Form der "Vektorisierung" dar, also der Organisation von Programm-Code (sei es durch optimierende Compiler oder durch den Programmierer selbst) mit dem Ziel der Optimierung der Behandlung von Vektoren.
Vektorisierung war schon immer die Zauberformel für Supercomputer mit ihren aus vielen einzelnen Prozessoren gebildeten Parallel-Architekturen. Auf diesen Architekturen wird versucht, die Rechenlast möglichst gleichmäßig auf alle Prozessoren zu verteilen und so die Ausführungsgeschwindigkeit zu maximieren. Die sogenanten "divide and conquer"-Algorithmen spalten kompliziertere numerische Aufgaben in kleine Schleifen über Vektorelemente auf. Hochgezüchtete Compiler finden dann den effizientesten Weg für die Verteilung der Vektor-Elemente auf die Prozessoren. Viele Compiler für Supercomputer enthalten bereits große Bibliotheken vordefinierter Vektor- und Matrixfunktionen für viele Anwendungszwecke. Diese Vektor- und Matrixfunktionen bieten den besten Weg, maximalen Datendurchsatz zu erzielen.
Es ist offensichtlich, daß die massive Parallelverarbeitung einer Cray auf den meisten PCs mit ihren eher bescheidenen 2, 4 oder allenfalls 8 Prozessor-Kernen nicht in gleicher Weise möglich ist. Auf den ersten Blick mag es daher sinnlos erscheinen, das Konzept der vektorisierten Programmierung auch auf dem PC anzuwenden. Tatsächlich aber sind auch viele vektor-spezifische Optimierungen möglich, selbst wenn nur eine CPU vorhanden ist. Viele dieser Optimierungen können von heutigen Compilern nicht direkt durchgeführt werden. Stattdessen muß der Programmierer auf Maschinensprachen-Niveau heruntergehen. Hand-optimierte, in Maschinensprache geschriebene Vektorfunktionen übertreffen compilierte Schleifen in der Geschwindigkeit durchschnittlich um einen Faktor von 2-3. Dies bedeutet, daß Vektorisierung die Mühe sehr wohl lohnen kann, auch für PC-Programme.
1.1.1 Allgemeine Optimierungs-Strategien von OptiVec
Hier sind die wichtigsten Optimierungs-Strategien, die in OptiVec zur Steigerung der Performance auf eingesetzt werden &150; unabhängig von der Zahl der Prozessor-Kerne:
Prefetch von Gruppen von Vektor-Elementen
Ab dem Pentium III stehen sehr nützliche "Prefetch"-Befehle zur Verfügung, die es erlauben, Daten schon genügen im voraus aus dem Hauptspeicher in den Prozessor zu laden, so daß sie gleich zur Verfügung stehen, wenn sie verarbeitet werden sollen.
Cache-Kontrolle
Der Pentium III+ -Befehlssatz erlaubt es, Daten als "temporär" (zur Wiederverwendung vorgesehen) oder "nicht-temporär" (nur einmal verwendet) zu markieren, wenn sie geladen oder gespeichert werden. OptiVec-Funktionen gehen generell von der Annahme aus, daß Eingabevektoren (oder -matrizen) nicht noch einmal benutzt werden, während Ausgabevektoren wahrscheinlich ihrerseits zu Eingabedaten für folgende Operationen werden. Dementsprechend wird der Cache beim Laden von Eingabedaten umgangen, während Ausgabedaten in den Cache geschrieben werden. Natürlich wird dieses Schema zusammenbrechen, wenn Vektoren gar nicht mehr in den Cache passen. Für solche Fälle ist die "Large-Vector"-Version der OptiVec-Bibliotheken gedacht, die auch beim Speichern der Ausgabedaten den Cache umgeht. Für einfache arithmetische Operationen kann hierdurch im Vergleich zur Version für kleine und mittlere Vektoren ein Geschwindigkeitsgewinn von bis zu 20% erzielt werden. Da andererseits die "Large-Vector"-Version effektiv den Cache ausschaltet, resultiert ein drastisch verschlechterter Datendurchsatz (bis zu einem Faktor von 3-4) von ihrem eventuellen Mißbrauch für kleinere Vektoren, wo der Cache hätte benutzt werden können. Bevor Sie tatsächlich die "Large-Vector"-Version einsetzen, sollten Sie daher auch prüfen, ob sich Ihr Problem nicht in kleinere Vektoren aufspalten läßt, wodurch der Cache wieder genutzt und ein enormer Geschwindigkeitsvorteil erzielt werden könnte.
Verwendung von SIMD-Befehlen
Man mag sich wundern, warum diese Strategie nicht gleich an erster Stelle genannt ist. Die SSE oder "Streaming Single-Instruction-Multiple-Data Extensions" des Pentium III und Pentium 4 bieten explizite Unterstützung für Vektor-Programmierung mit Fließkommazahlen in float / single- oder double- Genauigkeit (letztere nur für Pentium 4). Auf den ersten Blick sollten sie also die Vektor-Programmierung auf dem PC geradezu revolutionieren. Angesichts einer immer noch vorhandenen Diskrepanz zwischen Prozessor- und Datenbus-Geschwindigkeit sind aber viele der einfachen arithmetischen Operationen in ihrer Geschwindigkeit durch den Datenfluß begrenzt. Hier können SIMD-Befehle nur noch zu einem geringeren Geschwindigkeitsvorteil führen, als man eigentlich erwarten würde. Die gleichzeitige Verarbeitung von vier float-Zahlen in einem einzigen Befehl erbringt so häufig nur eine Beschleunigung um 20-30% gegenüber gutem FPU-Code, was sich natürlich immer noch lohnt. Für kompliziertere Operationen allerdings können SIMD-Befehle oft gar nicht verwendet werden, wenn nämlich entweder bedingte Verzweigungen für jedes Vektor-Element individuell erforderlich sind, oder auch dann, wenn ohne die interne extended-Genauigkeit der FPU umständlichere Algorithmen gewählt werden müßten. OptiVec macht daher von den SSE-Befehlen überall dort Gebrauch, wo ein wirklicher Geschwindigkeitsvorteil erzielt werden kann. Man beachte allerdings, dass Operationen wie Matrix-Multiplikation oder Fourier-Transformation in float-Präzision zugunsten des hier möglichen erheblichen Geschwindigkeitsgewinnes einen Genauigkeitsverlust von 2-3 Stellen in Kauf nehmen. Wer demgegenüber auf maximale Genauigkeit Wert legen muss, sollte daher stets die ausschließlich FPU-Befehle verwendende P4-Version einsetzen.
Preload von Fließkomma-Konstanten
Anstatt Fließkomma-Konstanten am Ende jedes Funktionsaufrufes innerhalb einer Schleife von Coprozessor-Stack zu entfernen, bleiben sie für die Verarbeitung des nächsten Vektor-Elementes geladen.
Volle XMM- und FPU-AusnutzungWo immer nötig und sinnvoll, werden alle acht XMM-Register (in der 64-bit-Version sogar sechzehn) bzw. alle acht Coprozessor-Register eingesetzt (für einen Compiler ist es schon eine hervorragende Leistung, die Buchführung für vier Coprozessor-Register zu beherrschen).
Superscalar schedulingDurch sorgfältige "Paarung" von Befehlen, deren Ergebnisse nicht voneinander abhängen, können die parallelen Integer-Pipes und fadd/fmul-Einheiten moderner Prozessoren (seit Pentium) bestmöglich ausgenutzt werden.
Ältere Prozessoren profitieren hiervon nicht, zumeist schadet es aber auch nicht.
Loop-unrolling
Wo eine optimale Ausnutzung der parallelen Prozessor-Pipes nicht für einzelne Vektor-Elemente erzielt werden kann, werden die Vektor-Elemente häufig gleich zu zweit, zu viert oder noch mehreren verarbeitet. Hierdurch wird zusätzlich der relative Anteil des Schleifen-Managements an der gesamten Ausführungszeit zurückgedrängt. Im Zusammenhang mit den oben beschriebenen "Prefetch"-Mechanismen wird die Schleifengröße möglichst an die Cache-Zeilengröße von 64 Byte (32 Byte bei älteren Prozessoren) angepaßt.
Vereinfachte Adressierung
Die Adressierung von Vektor- und erst recht von Matrix-Elementen stellt noch immer eine Hauptquelle für ineffizienten Code heutiger Compiler dar. Durch Hin- und Herschaltung zwischen Eingabe- und Ausgabe-Vektoren wird eine große Zahl redundanter Adressierungs-Operationen ausgeführt. Durch die ebenso strikte wie einfache Definition "Verarbeitung von hier bis da" können die OptiVec-Funktionen den Aufwand für die Adressierung von Array-Elementen auf das nötige Minimum reduzieren.
Ersatz von Fließkomma- durch Ganzzahl-Befehle
Eine Reihe von Fließkomma-Operationen (wie Kopieren, Austauschen, Vergleich mit Sollwerten) kann wahlweise mit Ganzzahl- oder Fließkomma-Prozessorbefehlen implementiert werden. Hier wird natürlich die jeweils schnellste Methode angewandt.
Strikte Genauigkeits-Kontrolle
C/C++-Compiler wandeln eine float-Zahl in double um – Pascal/Delphi sogar in extended – bevor sie an eine mathematische Funktion übergeben wird. Diese Behandlung war einmal sinnvoll, als Festplattenspeicher zu teuer war, um in den .LIB-Dateien separate Funktionen für alle Datentypen einzuschließen. Auf heutigen PCs ist sie schlicht ineffizient. Konsequenterweise werden in den OptiVec-Routinen keine solchen impliziten Umwandlungen durchgeführt. Hier wird eine float-Funktion auch nur in float- (also einfacher) Genauigkeit berechnet, unter Verzicht auf die soundsovielte Stelle nach dem Komma, die ohnehin sofort wieder abgeschnitten wird. Zusätzlich kann V_setFPAccuracy( 1 ); aufgerufen werden, um die FPU auf einfache Genauigkeit umzuschalten, falls man sich generell mit dieser begnügen möchte. Hierdurch kann die Ausführungsgeschwindigkeit ab dem Pentium-Prozessor etwas gesteigert werden. Seien Sie aber darauf gefasst, dass die Genauigkeit Ihrer Endergebnisse noch deutlich unter der float-Spezifikation liegen kann, wenn schon die Zwischenergebnisse nur einfach-genau berechnet werden. Details werden bei V_setFPAccuracy aufgeführt.
Inline-Coding
Alle externen Funktionsaufrufe sind aus den Schleifen eliminiert. Dadurch wird die Ausführungszeit der "call / ret"-Paare sowie die Zeit für die Übergabe der Funktionsargumente eingespart.
Cache-line-Matching lokaler Variablen
Der Level-1-Cache aktueller Prozessoren ist in Zeilen von je 64 Byte organisiert (bei den Vorgängern waren es 32 Byte). Viele OptiVec-Funktionen benötigen doppelt- oder extended-genaue Variablen auf dem Stack (vor allem für Ganzzahl/Fließkomma-Umwandlungen oder für Bereichsprüfungen). Derzeit erhältliche Compiler richten den Stack an 4-Byte-Grenzen aus. Es besteht also die Gefahr, dass die 8 Bytes einer double oder die 10 bytes einer extended beim Speichern auf dem Stack eine 64-Byte-Grenze überschreiten. Dies wiederum würde zu starken Geschwindigkeits-Einbußen durch Cache-Zeilenumbrüche führen. Um diese zu vermeiden, richten alle OptiVec-Funktionen, für die dies eine Rolle spielt, ihre lokalen Variablen an 8-Byte- (für double), 16-Byte- (für extended) bzw. 64-Byte-Grenzen aus (XMM-Werte).
Ungeschützte und bereichsreduzierte Funktionen
OptiVec bietet alternative Formen einiger mathematischer Funktionen, bei denen man zwischen der geschützten Variante mit Fehlerbehandlung und einer ungeschützten Variante ohne Fehlerdetektion währen kann. In einigen Funktionen, die ganzzahlige Potenzen ausrechnen, erlaubt die Abwesenheit der Fehlerdetektion eine viel effizientere Codierung. Ähnliches gilt für die Sinus- und Cosinus-Funktion für mit Sicherheit zwischen -2p und +2p liegenden Argumenten. In diesen Spezialfällen kann die Ausführungszeit um bis zu 40% reduziert werden, abhängig von der Hardware-Umgebung. Dieser Geschwindigkeitsgewinn wird allerdings durch erhöhtes Risiko erkauft: Falls auch nur ein einziges Vektorelement außerhalb des gültigen Bereiches liegt, stürzen die ungeschützten und bereichsreduzierten Funktionen ohne Warnung einfach ab.
1.1.2 Multi-Prozessor-Optimierung
MultithreadSupport
Moderne Betriebssysteme erlauben es, innerhalb eines Programmes parallel laufende Threads auf die vorhandenen Prozessorkerne zu verteilen so die Performance gegenüber Single-Thread-Verarbeitung zu vervielfachen. Hierfür muß aber sichergestellt sein, daß in parallelen Threads laufende Funktionen sich nicht gegenseitig ihre Zwischenergebnisse überschreiben. Mit sehr wenigen Ausnahmen (namentlich den Plotting-Funktionen) sind alle übrigen OptiVec-Funktionen re-entrant, also darauf ausgerichtet, parallel zueinander laufen zu können.
Bei der Entwicklung Ihrer Multi-Thread-Anwendung stehen Ihnen zwei grundsätzlich verschiedene Optionen zur Verfügung: Funktionale Parallelität und Daten-Parallelität.
Funktionelle Parallelität
Verschiedene Threads führen verschiedene Aufgaben aus – sie unterscheiden sich in ihrer Funktion. Als Beispiel denke man an eine Anwendung, bei der ein Thread Benutzer-Ein- und Ausgaben abarbeitet, während ein anderer Thread Hintergrund-Berechnungen durchführt. Selbst auf einer Ein-Kern-CPU kann diese Art des Multi-Threading durch die vom Betriebssystem bewirkte ständige Umschaltung zwischen den beiden Threads Vorteile bieten (z.B., dass das Benutzer-Interface nicht blockiert, während die Hintergrundberechnungen ausgeführt werden, sondern weiterhin Eingaben annehmen kann). Auf einem Mehr-Prozessor-Computer können die zwei (oder mehr) Threads tatsächlich gleichzeitig auf den verschiedenen Prozessor-Kernen laufen. Normalerweise ist die Lastverteilung zwischen den Prozessoren bei funktionellem Multi-Threading alles andere als perfekt: Oft läuft ein Prozessor unter Volllast, während ein anderer arbeitslos auf Eingaben wartet. Dennoch ist diese Art des Multi-Threading die beste Option für Anwendungen, die nur kleine bis mittelgroße Vektoren und Matrizen umfassen.
Daten-Parallelität
Um die Lastverteilung zwischen den vorhandenen Prozessor-Kernen zu verbessern und so den Datendurchsatz zu maximieren, kann die klassische Parallelverarbeitung angewandt werden: Die Daten-Vektoren und -Matrizen werden in kleinere Teile zerlegt, und jeder Thread arbeitet einen solchen Teil ab. Die Brauchbarkeit dieses Ansatzes wird dadurch beschränkt, dass der Aufwand für die Verteilung der Daten auf die verschiedenen Threads und für die dabei nötige Kommunikation der Threads untereinander ziemlich hoch ist. Außerdem lassen sich die Daten niemals vollständig parallelisieren; es verbleibt immer ein gewisser Teil der Aufgaben, der nur sequentiell abgearbeitet werden kann. Daher lohnt sich Daten-Parallelität nur für größere Vektoren und Matrizen. Typische Schwellen-Größen, ab denen die Leistung mehrerer Prozessoren den für die Verteilung auf sie nötigen Aufwand "zurückverdient", reichen von unter 100 (bei mathematischen Funktionen komplex-zahliger Vektoren) bis zu über 10.000 Elementen (bei den einfachen arithmetischen Funktionen). Erst wenn die Vektoren / Matrizen deutlich größer als diese Schwellenwerte sind, kommt die erhöhte Leistung voll zum Tragen. Dann erst nähert sich die Beschleunigung dem theoretischen Grenzwert einer Verdopplung, Vervierfachung usw. an.
1.1.3 Unterstützung für CUDA-Hardware
Moderne Graphik-Karten sind mit bis zu mehreren hundert Prozessorkernen bestückt, die alle parallel laufen können. In den letzten Jahren wurden Interfaces entwickelt, die es erlauben, diese geballte Rechenpower außer für Graphik- auch für allgemeine Berechnungen nutzbar zu machen. Einer dieser Ansätze ist das CUDA-Konzept von NVIDIA. Alle aktuellen NVIDIA-Graphikkarten unterstützen CUDA. Außerdem bietet NVIDIA spezielle Hochleistungs-Hardware an, die von vornherein nicht als Graphikkarten, sondern gewissermaßen als Vektor-Coprozessor gedacht ist. Mit den cudaOptiVec-Bibliotheken (gekennzeichnet durch ein "C" im Namen, z.B. OVVC8C.LIB oder OVBC64_8C.a) bietet OptiVec einen einfachen Weg, um CUDA-Hardware für Vektor-/Matrix-Berechnungen zu nutzen - ohne die Schwierigkeiten tatsächlicher CUDA-Programmierung. Es gibt einige Punkte zu beachten:
- Einleuchtenderweise können die cudaOptiVec-Bibliotheken nur mit CUDA-fähiger Hardware benutzt werden. Das bedeutet, dass nur Graphikkarten und Boards von NVIDIA unterstützt werden (minimale "compute-capability": 2.0).
- Schon Graphikkarten für unter 80 EUR können die Performance für einige Funktionen um einen Faktor von 10 steigern, Hochleistungs-Karten noch um wesentlich mehr. Umgekehrt kann die Kombination einer High-End CPU mit einer Low-End Graphikkarte (wie sie häufig in Laptops zu finden ist) nur wenig vom Einsatz der cudaOptiVec-Bibliotheken profitieren.
- Die Kosten für das Hin-und-Herschieben von Daten zwischen Haupt- und Graphik-Speicher (in den für CUDA gebräuchlichen Termini: "Host"- und "Device"-Memory) sind so hoch, dass sie nur für ziemlich große Vektoren und Matrizen wieder eingespielt werden können. So lohnt sich der CUDA-Einsatz für mathematische Funktionen wie sin oder exp erst ab mehreren 10 000 Vektor-Elementen.
- Der Gebrauch von CUDA mit OptiVec kann sich sehr einfach gestalten, indem einfach anstelle der "normalen" OptiVec-Bibliotheken die cudaOptiVec-Bibliotheken eingebunden werden. Es sind nicht einmal Modifikationen des Quell-Codes notwendig.
- Wenn Sie allerdings doch die Mühe auf sich nehmen wollen, Ihren Quellcode anzupassen, gibt es Wege, um die Performance sehr deutlich gegenüber dieser einfachsten Vorgehensweise zu steigern. Hierfür bieten die cudaOptiVec-Bibliotheken verschiedene Sets von Funktionen, die sich durch ihre Präfixe unterscheiden:
- VF_, VFx_ etc. (die "normalen" Präfixe): Automatischer Gebrauch von CUDA. Alle OptiVec-Funktionen machen eine Abschätzung, ob sich die Auslagerung auf den Graphikprozessor (in CUDA-Diktion: "Device") lohnt, und entscheiden sich dementsprechend, CUDA zu nutzen oder doch auf der CPU (dem "Host") zu bleiben. Dieser Entscheidungs-Mechanismus ist allerdings alles andere als vollkommen, da er nicht auf einfache Weise "wissen" kann, wie gut und schnell die Graphikkarte relativ zur CPU tatsächlich ist.
- VFcu_, VFxcu_, etc. (mit "cu" hinter dem originalen Präfix, direkt vor dem Unterstrich): Erzwingt Auslagerung auf den CUDA Device. Der Gebrauch dieser Präfixe macht am meisten Sinn, wenn der automatische Entscheidungs-Mechanismus ausgeschaltet ist durch Aufruf von V_setAutoCudaUse( 0 );
- cudaVF_, cudaVFx_, etc. (mit vorangestelltem "cuda" vor dem originalen Präfix): Verarbeitet Daten auf dem CUDA Device, die sich bereits im Device-Memory befinden (oder in pinned Host-Memory). Um diese Präfixe zu verwenden, muss der Speichertransfer zwischen Haupt- und Device-Speicher selbst vorgenommen werden. cudaOptiVec stellt die nötigen Interface-Funktionen hierfür (als Spezialisierungen der entsprechenden CUDA-Runtime-Funktionen) zur Verfügung.
- NVIDIA kann jederzeit die Lizenzbedingungen für ihre CUDA-Bibliotheken ändern. Wir erwarten zwar, dass NVIDIA die bisherige offene Politik bebehält; es kann aber von unserer Seite keine Garantie geben, dass OptiVec dauerhaft CUDA unterstützen kann.
- Eine Schritt-für-Schritt-Einführung für die Benutzung von OptiVec mit CUDA befindet sich in CudaOptiVec.HTM (derzeit nur auf Englisch).
1.1.4 Auswahl der passenden OptiVec-Bibliothek
Wenn Ihre Anwendung auf einem breiten Spektrum unterstützter Prozessoren laufen sollen und wenn Ihre Vektoren / Matrizen nur von kleiner bis mittlerer Größe sind (wenige 100 bis wenige 1000 Elemente, je nach Art der durchgeführten Berechnungen), empfehlen wir die Allzweck-Bibliotheken OVVC4.LIB (für MS Visual C++), VCF4W.LIB (für Borland C++), oder die Units in OPTIVEC\LIB4 (für Delphi). Diese Bibliotheken verbinden gute Performance mit Rück-Kompatibilität zu älterer Hardware bis hinab zu 486DX, Pentium und den frühen Modellen des Athlon. Sie alle sind Thread-sicher und unterstützen funktionelle Parallelität. Falls Sie nicht die volle Fließkomma-Genauigkeit und auch nicht dieses Ausmaß an Rückwärts-Kompatibilität benötigen, können Sie höhere Leistungen erzielen durch den Einsatz der P8-Bibliotheken für oder Core2xxx / AMD64xxx mit SSE3 (gekennzeichnet durch die Ziffer "8"), oder der P9-Bibliotheken (Intel "Haswell", AMD "Steamroller" mit AVX und AVX2).
Für mittlere bis große Vektoren und Matrizen auf Mehrkern-Maschinen bietet sich die Verwendung der multi-core-optimierten Bibliotheken an. Diese verteilen für jede einzelne Funktion die Arbeitslast über die vorhandenen Prozessor-Kerne (Auto-Threading). Sie werden durch den Buchstaben "M" gekennzeichnet, also z.B. OVVC8M.LIB (für MS Visual C++ mit SSE3-Verwendung), VCF4M.LIB (für Embarcadero/Borland C++ mit maximaler Rückwärts-Kompatibilität), oder die Units in OPTIVEC\LIB8M (für Delphi). Diese Bibliotheken sind für Multiprozessor-Computer wie AMD64 X2, Intel i5, Core2Duo oder Workstations mit mehreren Chips auf mind. Pentium 4+-Level gedacht.
Die CUDA-Bibliotheks-Versionen basieren auf den "M"-Bibliotheken und lagern die Verarbeitung nur für sehr große Vektoren auf die Graphik-Karte aus. Sie sind durch den Buchstaben "C" markiert, z.B. OVVC8C.LIB.
Die "M"- und "C"- Bibliotheken laufen immer noch auf Ein-Kern-Computern. Durch die "Bürokratie-Verluste" beim Thread-Management sind sie hier aber deutlich langsamer als die Allzweck-Bibliotheken. Obwohl die "M"-Bibliotheken im Hinblick auf mittlere bis größere Vektoren entwickelt wurden, sind die Einbußen bei Verwendung mit kleinen Vektoren nicht sehr hoch, da die OptiVec Thread-Engine eine Funktion automatisch in einem einzelnen Thread ausführt, wenn die Vektor-Größe nicht ausreicht, um den Verteilungs-Aufwand durch die Parallel-Ausführung (oder gar durch die Auslagerung auf den Graphik-Prozessor) wieder aufzuholen.
Wenn Sie die "M"- oder "C"-Bibliotheken verwenden, muss Ihr Programm zu Beginn V_initMT aufrufen.
Zurück zum VectorLib-Inhaltsverzeichnis OptiVec Home
2. Elemente von VectorLib-Funktionen
2.1 Synonyme einiger Datentypen
Um größtmögliche Flexibilität und Vollständigkeit von OptiVec zu gewährleisten, wurden zusätzliche Datentypen in <VecLib.h> bzw. der Unit VecLib eingeführt:
a) nur C/C++:
Der Datentyp ui (kurz für "unsigned index") wird für die Indizierung von Arrays benutzt und ist in <VecLib.h> als Synonym für size_t definiert, also für Win32 als unsigned int bzw. für Win64 als unsigned __int64.
64-bit-Integers (__int64 in BC++ Builder und MS Visual C++, Int64 in Delphi, Comp in Turbo Pascal) werden in OptiVec als quad (für "quadruple integer", also Vierfach-Integer) bezeichnet.
Der Datentyp quad ist in 32-bit immer vorzeichenbehaftet; nur für Win64 bietet OptiVec den Datentyp uquad als vorzeichenlosen 64-bit Ganzzahltyp.
- Nur Borland C++ vor C++ Builder 2006: Da diese älteren BC-Versionen keine direkte Unterstützung für 64-bit Integers boten, ist hier der Typ quad als struct von zwei 32-bit-Werten implementiert. Fließkommazahlen – vorzugsweise der über eine 64-bit-Mantisse verfügende Typ long double – zur " müssen zur Vermittlung" eingesetzt werden. Hierzu dienen die Funktionen setquad, quadtod und _quadtold. Alternativ können die beiden 32-bit-Teile auch einzeln zugewiesen werden, z.B.:.
xq.Hi = 0x00000001UL;
xq.Lo = 0x2468ABCDUL;
Der Pascal/Delphi-Benutzern wohlbekannte Datentyp extended wird in der Borland C++-Version von OptiVec als Synonym für long double verwendet. Da Visual C++ 80-bit-Fließkommazahlen nicht unterstützt, ist extended hier als double definiert.
Der Grund für die Einführung des Typs extended ist, daß alle OptiVec-Funktionen identische Namen in C/C++ und Pascal/Delphi haben sollen. Die Funktions-Präfixe aber sind vom Datentyp der verarbeiteten Vektoren abgeleitet (s.u.). Der Buchstabe "L" (der vielleicht für long double stehen könnte) ist bereits durch long int und unsigned long überbelegt. So bietet sich der Buchstabe "E" für extended an, was den zusätzlichen Vorteil der Nähe zu den Buchstaben "D" für double und "F" für float hat. In alphabetischer Nachbarschaft sind die Buchstaben "G" und "H" bereits für "great" (128-bit float) und "half" (16-bit float) reserviert.
b) nur Pascal/Delphi:
Der Datentyp Float wird von C/C++ als Synonym für Single übernommen. Wir ziehen es vor, die Buchstaben, die die Fließkomma-Datentypen bezeichnen, in alphabetischer Nachbarschaft zu haben: "D" für Double, "E" für Extended und "F" für Float. Wie oben erwähnt, können künftige 128-bit- und 256-bit-Fließkommazahlen ihren Platz in dieser Reihe als "G" für Great und "H" für Hyper finden.
Aus "historischen" Gründen weisen die Ganzzahl-Datentypen eine etwas konfuse Nomenklatur in Pascal/Delphi auf. Um die vom Datentyp abgeleiteten Präfixe mit der C/C++-Version von OptiVec kompatibel zu machen, definieren wir eine Anzahl von Synonymen, wie in der folgenden Tabelle beschrieben:
| type | Pascal/Delphi-Name | Synonym | abgeleitetes Präfix |
| 8 bit signed | ShortInt | ByteInt | VBI_ |
| 8 bit unsigned | Byte | UByte | VUB_ |
| 16 bit signed | SmallInt | | VSI_ |
| 16 bit unsigned | Word | USmall | VUS_ |
| 32 bit signed | LongInt | | VLI_ |
| 32 bit unsigned | | ULong | VUL_ |
| 64 bit signed | Int64 | QuadInt | VQI_ |
| 64 bit unsigned | UInt64 | UQuad | VUQ_ |
| 16/32 bit signed | Integer | | VI_ |
| 16/32 bit unsigned | Cardinal | UInt | VU_ |
UQuads existieren nur in der 64-bit-Version. Für Win32 gibt es nur den vorzeichenbehafteten Typ Quad.
Um einen Bool'schen Datentyp derselben Größe wie Integer zur Verfügung zu haben, definieren wir den Typ IntBool. Er ist äquivalent mit LongBool. Man findet den Typ IntBool vor allem als Rückgabewert vieler mathematischer VectorLib-Funktionen.
2.2 Komplexe Zahlen:
Die Datentypen fComplex, dComplex, eComplex, fPolar, dPolar und ePolar
Bezüglich der Unterstützung komplexer Zahlen herrscht ein gewisses Durcheinander in den gebräuchlichen Programmier-Sprachen. Der ANSI-Standard von C bietet lediglich eine Struktur complex (für aus doubles bestehende Real- und Imaginärteile). Borland C fügt dem eine Struktur _complexl für aus long doubles bestehende komplexe Zahlen hinzu. Real- und Imaginärteil werden dabei als x und y bezeichnet. Die einzige vorhandene Funktion
für komplexe Zahlen ist die Bildung des Absolutwertes.
Schon seit frühen Versionen bot Borland C++ die Klasse complex, die mit doubles arbeitet. Hier sind Real- und Imaginärteil nur über die Funktionen real und imag zugänglich. Die Klasse complex bietet eine ganze Reihe arithmetischer Operationen und mathematischer Funktionen.
Erst die Standard C++ Library definierte komplexe Klassen für alle drei Genauigkeiten.
Die neueren Versionen von Delphi bieten eine Unit Complex, die komplexe Zahlen als Varianten-Typen führt – mit allen dadurch verursachten Ineffizienzen.
Komplexe Funktionen in Polarkoordinaten werden bislang von keinem dieser Produkte geboten.
In den meisten Compilern sind die komplexen Operationen sehr ineffizient und vor allem ungenau implementiert (nur die Lehrbuchformel einer komplexen Funktion hinzuschreiben, wie es meist geschieht, wird nur für einen sehr begrenzten Bereich von Argumenten brauchbare Ergebnisse liefern!).
Unsere Ziele sind
- komplexe Zahlen in allen drei Genauigkeiten für C, C++, Pascal und Delphi zur Verfügung zu stellen
- sowohl cartesische als auch Polar-Koordinaten zu unterstützen
- eine saubere, effiziente Implementierung in Assembler zu liefern (anstelle der gebräuchlichen C++ Templates)
- und eine einfache, kompakte und konsistente Nomenklatur einzuführen.
Hierfür wurde die Bibliothek CMATH geschaffen und wird mit OptiVec ausgeliefert. Sie wird in der Datei CMATHD.HTM näher beschrieben. Wenn Sie irgendeine der nicht-vektorisierten Funktionen von CMATH mit C/C++ benutzen, müssen Sie <newcplx.h> (für C++-Module) oder <cmath.h> (für einfache C-Module) vor (!) den übrigen OptiVec-Include-Dateien einschließen.
Auch ohne explizite Einbindung von CMATH stellt OptiVec die grundlegenden Datentypen und Initialisierungs-Möglichkeiten in <VecLib.h> bzw. der Unit VecLib zur Verfügung. Falls Sie nur diese verwenden, brauchen Sie CMATH nicht explizit einzuschließen.
Die für C/C++ in <VecLib.h> definierten komplexen Typen lauten:
typedef struct { float Re, Im; } fComplex;
typedef struct { double Re, Im; } dComplex;
typedef struct { extended Re, Im; } eComplex;
typedef struct { float Mag, Arg; } fPolar;
typedef struct { double Mag, Arg; } dPolar;
typedef struct { extended Mag, Arg; } ePolar;
(Der Datentyp extended wird als Synonym für long double verwendet, s. oben.)
Die entsprechenden Definitionen für Pascal/Delphi sind in der Unit VecLib enthalten:
type fComplex = record Re, Im: Float; end;
type dComplex = record Re, Im: Double; end;
type eComplex = record Re, Im: Extended; end;
type fPolar = record Mag, Arg: Float; end;
type dPolar = record Mag, Arg: Double; end;
type ePolar = record Mag, Arg: Extended; end;
Komplexe Zahlen werden initialisiert, indem ihrem Real- und Imaginärteil bzw. ihrem Mag- und Arg-Teil die gewünschten Werte zugewiesen werden, z.B.:
z.Re = 3.0; z.Im = 5.7;
p.Mag = 8.8; p.Arg = 3.14;
(Für Pascal/Delphi muß der Zuweisungs-Operator natürlich ":=" geschrieben werden).
Alternativ kann die Initialisierung auch mittels der Funktionen fcplx oder fpolr durchgeführt werden:
C/C++:
z = fcplx( 3.0, 5.7 );
p = fpolr( 4.0, 0.7 );
Pascal/Delphi:
fcplx( z, 3.0, 5.7 );
fpolr( p, 3.0, 5.7 );
Für doppelt-genaue komplexe Zahlen gebrauche man dcplx und dpolr, für extended-genaue ecplx und epolr.
Zeiger auf komplexe Felder oder Vektoren werden mithilfe der Datentypen cfVector, cdVector und ceVector (für cartesisch-komplexe Vektoren) sowie pfVector, pdVector und peVector (für Vektoren komplexer Zahlen in Polarkoordinaten) definiert, wie unten beschrieben.
2.3 Vektoren und Arrays:
Die Datentypen fVector, dVector, eVector,
cfVector, cdVector, ceVector, pfVector, pdVector, peVector,
iVector, biVector, siVector, liVector, qiVector,
uVector, ubVector, usVector, ulVector und uiVector
Wie üblich definieren wir einen "Vektor" als ein eindimensionales Daten-Feld (oder Array), das aus mindestens einem Element besteht(!) und dessen Elemente alle demselben Datentyp angehören. Etwas mathematischer definiert ist ein Vektor ein Tensor vom Rang 1. Ein zweidimensionales Feld (also ein Tensor vom
Rang 2) wird hier als "Matrix" bezeichnet, höher-dimensionale Felder generell als Tensoren.
Im Unterschied zu anderen Ansätzen erlaubt VectorLib keine Vektoren der Länge 0!
Die Basis aller VectorLib-Funktionen bilden die Vektor-Datentypen, die in <VecLib.h> bzw. der Unit VecLib definiert und unten aufgelistet sind. Im Unterschied zu den statischen Arrays, die immer eine beim Compilieren
festgelegte Größe besitzen, arbeiten die VectorLib-Typen mit dynamischer Speicherzuweisung und daher mit variablen Größen. Wegen dieser Flexibilität empfehlen wir den vorzugsweisen Gebrauch der letzteren. Hier sind sie also:
C/C++
| typedef | float * | fVector |
| typedef | double * | dVector |
| typedef | extended * | eVector |
| typedef | fComplex * | cfVector |
| typedef | dComplex * | cdVector |
| typedef | eComplex * | ceVector |
| typedef | fPolar * | pfVector |
| typedef | dPolar * | pdVector |
| typedef | ePolar * | peVector |
| typedef | int * | iVector |
| typedef | byte * | biVector |
| typedef | short * | siVector |
| typedef | long * | liVector |
| typedef | quad * | qiVector |
| typedef | unsigned * | uVector |
| typedef | unsigned byte * | ubVector |
| typedef | unsigned short * | usVector |
| typedef | unsigned long * | ulVector |
| typedef | uquad * | uqVector |
| typedef | ui * | uiVector |
| |
Pascal/Delphi
| type | fVector | = ^Float; |
| type | dVector | = ^Double; |
| type | eVector | = ^Extended; |
| type | cfVector | = ^fComplex; |
| type | cdVector | = ^dComplex; |
| type | ceVector | = ^eComplex; |
| type | pfVector | = ^fPolar; |
| type | pdVector | = ^dPolar; |
| type | peVector | = ^ePolar |
| type | iVector | = ^Integer; |
| type | biVector | = ^ByteInt; |
| type | siVector | = ^SmallInt; |
| type | liVector | = ^LongInt; |
| type | qiVector | = ^QuadInt; |
| type | uVector | = ^UInt; |
| type | ubVector | = ^UByte; |
| type | usVector | = ^USmall; |
| type | ulVector | = ^ULong; |
| type | uqVector | = ^UQuad; |
| | |
|
Intern handelt es sich also bei einem Datentyp wie fVector um einen "Zeiger auf float". Man sollte ihn sich allerdings lieber als "float-Vector" vorstellen.
|
N.B.: In der Windows-Programmierung wird häufig der Buchstabe l" oder L"
eingesetzt, um long int-Variablen zu bezeichnen. Um Verwechslungen vorzubeugen, wird hier für long int stets das aus zwei Buchstaben bestehende Kürzel "li" oder "LI" verwendet und für unsigned long das Kürzel "ul" oder "UL". Konflikte mit den Präfixen für long double-Vektoren werden durch Ableitung deren Kürzel vom Alias-Namen "extended" und den Gebrauch von "e", "ce", "E" und "CE" umgangen, wie bereits oben und auch in den folgenden Abschnitten beschrieben. |
C/C++-spezifisch:
Um auf Vektor-Elemente zuzugreifen, wird wie für statische Arrays der Operator [] verwendet, z.B. VA[375] = 1.234;
Alternativ können die typenspezifischen Funktionen VF_element (gibt den Wert des gewünschten Elementes zurück, der mit dieser Funktion aber nicht überschrieben werden kann) und VF_Pelement (gibt einen Zeiger auf das gewünschte Element zurück) verwendet werden. Insbesondere einige ältere Borland C-Versionen haben einen Fehler in der Pointer-Arithmetik, der die Verwendung von VF_Pelement anstelle der Schreibweise X+n für einen Zeiger auf das n-te Element nötig macht. VF_Pelement kann zur Zuweisung einzelner Vektor-Elemente verwendet werden, z.B.:
*VF_Pelement( X, 3 ) = 5.7;
In Ihren Programmen können Sie die dynamischen OptiVec-Vektoren mit klassischen statischen C-Arrays mischen.
Beispiel:
float a[100]; /* klassischer statischer Array */
fVector b=VF_vector(100); /* VectorLib-Vektor */
VF_equ1( a, 100 ); /* setze die ersten 100 Elemente von a = 1.0 */
VF_equC( b, 100, 3.7 ); /* setze die ersten 100 Elemente von b = 3.7 */
Pascal/Delphi-spezifisch:
Der Zugriff auf einzelne Elemente dynamisch erzeugter Vektoren ist bei Pascal/Delphi nicht mit dem Operator [] möglich, sondern nur über die typenspezifischen Funktionen VF_element (gibt den Wert des gewünschten Elementes zurück, der mit dieser Funktion aber nicht überschrieben werden kann) und VF_Pelement (gibt einen Zeiger auf das gewünschte Element zurück). VF_Pelement kann zur Zuweisung einzelner Vektor-Elemente verwendet werden, z.B.:
VF_Pelement( X, 3 )^ := 5.7;
Wie in C/C++ können die VectorLib-Vektortypen mit statischen Arrays des klassischen Pascal-Stils gemischt werden. Statische Arrays müssen mit Hilfe des Adress-Operators an OptiVec-Routinen übergeben werden. Hier lautet das oben für C/C++ gegebene Beispiel:
a: array[0..99] of Single; (* klassischer statischer Array *)
b: fVector;(* VectorLib-Vektor *)
b := VF_vector(100);
VF_equ1( @a, 100 ); (* setze die ersten 100 Elemente von a = 1.0 *)
VF_equC( b, 100, 3.7 ); (* setze die ersten 100 Elemente von b = 3.7 *)
Delphi bietet zusätzlich auch dynamisch allozierte Arrays, die ebenfalls als Argumente an OptiVec-Funktionen übergeben werden können. Die folgende Tabelle vergleicht die Zeiger-basierten Vektoren von VectorLib mit den verschiedenen Array-Typen von Pascal/Delphi:
| | OptiVec-Vektoren | Pascal/Delphi-Arrays (statisch/dynamisch) |
| Ausrichtung des ersten Elements | an 32-byte-Grenze für optimale Cache-Zeilen-Anpassung | 2- oder 4-byte-Grenze (kann Zeilenumbruchs-Strafzyklen für double, QuadInt zur Folge haben) |
| Ausrichtung folgender Elemente | gepackt (d.h. keine Dummy-Bytes zwischen Elementen, auch nicht für 10- und 20-bit-Typen) | Arrays müssen in Delphi als "packed" deklariert werden, um kompatibel mit OptiVec zu sein |
| Index-Bereichsprüfung | keine | automatisch mittels eingebauter Größeninformation |
| dynamische Speicherzuweisung | function VF_vector, VF_vector0 | procedure SetLength (nur Delphi) |
| Initialisierung mit 0 | optional durch Aufruf von VF_vector0 | immer (nur Delphi) |
| Freigabe | function V_free, V_freeAll | procedure Finalize (nur Delphi) |
| einzelne Elemente lesen | function VF_element:
a := VF_element(X,5);
nur Delphi: typecast in Array ebenfalls möglich:
a := fArray(X)[5]; | Index in eckigen Klammern:
a := X[5]; |
| einzelne Elemente schreiben | function VF_Pelement:
VF_Pelement(X,5)^ := a;
nur Delphi: typecast in Array ebenfalls möglich:
fArray(X)[5] := a; | Index in eckigen Klammern:
X[5] := a; |
| Übergabe an OptiVec-Funktion | direkt:
VF_equ1( X, sz ); | Adress-Operator:
VF_equ1( @X, sz ); |
| Übergabe von Subvektor an OptiVec-Funktion | function VF_Pelement:
VF_equC( VF_Pelement(X,10), sz-10, 3.7); | Adress-Operator:
VF_equC( @X[10], sz-10, 3.7 ); |
Zusammenfassend läßt sich sagen, daß die Pascal/Delphi-Arrays etwas bequemer zu verwenden und durch die Index-Bereichsprüfung auch sicherer sind, während die Zeiger-basierten OptiVec-Vektoren schneller verarbeitet werden können (durch die bessere Speicherausrichtung und den Fortfall der Index-Bereichsüberprüfung).
Zurück zum VectorLib-Inhaltsverzeichnis OptiVec Home
2.4 Vektorfunktions-Präfixe
Jede OptiVec-Vektor-Funktion hat ein Präfix, das den Datentyp anzeigt, mit dem diese Funktion arbeitet. (Die präfix-losen überladenen C++-Versionen aller Funktionen sind im objekt-orientierten Interface VecObj definiert.)
| Prefix | Argumente und Rückgabewert |
| VF_ | fVector und float |
| VD_ | dVector und double |
| VE_ | eVector und extended (long double) |
| VCF_ | cfVector und fComplex |
| VCD_ | cdVector und dComplex |
| VCE_ | ceVector und eComplex |
| VPF_ | pfVector und fPolar |
| VPD_ | pdVector und dPolar |
| VPE_ | peVector und ePolar |
| VI_ | iVector und int / Integer |
| VBI_ | biVector und byte / ByteInt |
| VSI_ | siVector und short int / SmallInt |
| VLI_ | liVector und long int / LongInt |
| VQI_ | qiVector und quad / QuadInt |
| VU_ | uVector und unsigned / UInt |
| VUB_ | ubVector und unsigned char / UByte |
| VUS_ | usVector und unsigned short / USmall |
| VUL_ | ulVector und unsigned long / ULong |
| VUQ_ | uqVector und uquad / UQuad (nur für Win64 !) |
| VUI_ | uiVector und ui |
| V_ | (Datentyp-Umwandlungen wie V_FtoD sowie Datentyp-unabhängige Funktionen wie V_initPlot) |
Zurück zum VectorLib-Inhaltsverzeichnis OptiVec Home
3. Nur C++: VecObj, das objekt-orientierte Interface für VectorLib
VecObj, das objekt-orientierte C++-Interface für die Vektorfunktionen von OptiVec, wurde von Brian Dale, Case Western Reserve University, geschrieben. Die Erweiterung hiervon für Matrizen ist als MatObj ebenfalls vorhanden.
VecObj bietet u.a. die folgenden Vorzüge:
- automatische Speicherzuweisung und -freigabe
- vereinfachte Vektor-Behandlung
- stark vermindertes Risiko von Speicherfehlern
- erhöhte Sicherheit des Speicherzugriffs
- intuitive überladene Operatoren
- einfachere Funktionsaufrufe
Es gibt allerdings auch einige wenige Nachteile, die wir nicht verschweigen möchten:
- erhöhter Aufwand für den Compiler
- größerer Overhead (wie für jeden gekapselten C++-Code!) und als Folge hiervon
- erhöhte Programmcode-Länge
- leicht verminderte Rechengeschwindigkeit
- Vektoren können derzeit nur als Ganzes, nicht in Teilen verarbeitet werden
VecObj ist in den Include-Dateien <VecObj.h>, <fVecObj.h>, <dVecObj.h> etc. enthalten mit einer Include-Datei für jeden der in OptiVec unterstützten Datentypen.
Um das gesamte Interface (für alle Datentypen zusammen) zu laden, deklariere man
#include <OptiVec.h>.
Um irgendeine der Graphik-Funktionen von VectorLib zu verwenden, sollte stets <OptiVec.h> eingeschlossen werden.
MS Visual C++ und Borland C++ Builder (nicht aber frühere Borland C++-Versionen): Die Direktive
"using namespace OptiVec;"
sollte entweder im Funktionskörper jeder ein tVecObj verwendenden Funktion oder im globalen Deklarationsteil eines Programmes auftauchen. Der Platz in den einzelnen Funktionskörpern ist sicherer, da er potentielle Namespace-Konflikte mit anderen Funktionen vermeidet.
Die Vektor-Objekte werden als classes vector<T> implementiert, die die Vektor-Adresse (den Zeiger) und seine Größe size kapseln.
Für einfachere Verwendung wurden diesen Klassen Alias-Namen zugewiesen als fVecObj, dVecObj usw., wobei der Datentyp wie sonst in OptiVec durch den ersten oder die ersten beiden Buchstaben des Klassennamens angezeigt wird.
Alle VectorLib für einen bestimmten Datentyp definierten Funktionen sind als Member-Funktionen der betreffenden class tVecObj enthalten.
Die Konstruktoren können vier Formen annehmen:
vector(); // kein Speicher zugewiesen; size auf 0 gesetzt
vector( ui size ); // Vektor von size Elementen erzeugt
vector( ui size, T fill ); // desgleichen, aber mit "fill" initialisiert
vector( vector<T> init ); // erzeugt eine Kopie des Vektors "init"
Für alle Vektor-Klassen sind die arithmetischen Operatoren
+ - * / += -= *= /=
definiert, mit der Ausnahme, daß für die polar-komplexen Vektor-Klassen nur Multiplikationen und Divisionen, nicht aber Addition und Subtraktion unterstützt werden. Diese Operatoren stellen den einzigen Fall dar, in dem das Ergebnis einer Berechnung direkt einem Vektor-Objekt zugewiesen werden kann, wie z.B.
fVecObj Z = X + Y; oder
fVecObj Z = X * 3.5;
Man beachte aber, daß die Syntax-Regeln von C++ eine wirklich effiziente Implementierung dieser Operatoren nicht zulassen. Die arithmetischen Member-Funktionen sind wesentlich schneller. Wenn es auf Rechengeschwindigkeit ankommt, benutze man daher die letzteren anstelle der Operatoren-Syntax:
fVecObj Z.addV( X, Y ); oder
fVecObj Z.mulC( X, 3.5 );
Der Operator * bedeutet Multiplikation der einzelnen Elemente miteinander und nicht das Skalarprodukt zwier Vektoren.
Alle übrigen arithmetischen und mathematischen Funktionen können nur als Member-Funktion des betreffenden Ausgabe-Vektors aufgerufen werden, wie z.B. Y.exp(X). Obwohl es sicher logischer wäre, auch diese Funktionen so zu definieren, daß man stattdessen "Y = exp(X)" schreiben könnte, wurde die Syntax der Member-Funktionen gewählt, da sie wesentlich effizienter implementiert werden kann: Der einzige Weg, die zweite Variante zu implementieren, besteht darin, das Ergebnis der jeweiligen Funktion in einem temporären Vektor zwischenzuspeichern, der anschließend in Y kopiert wird. Hierdurch werden Rechenaufwand und Speicheranforderungen erhöht. Wir sind aber an Ihrer Meinung interessiert: Würden Sie trotzdem die Syntax "Y = func(X);" gegenüber der Member-Funktions-Syntax "Y.func(X);" vorziehen und ihre Nachteile in Kauf nehmen wollen? Bitte senden Sie uns Ihren Kommentar an support@optivec.de. Diese Syntax könnte in späteren Versionen von VecObj zur Verfügung gestellt werden.
Während die meisten VecObj-Funktionen Member-Funktionen des Ausgabe-Vektors sind, gibt es einige Funktionen, die gar keinen Ausgabe-Vektor haben. In diesen Fällen sind die Funktionen Member-Funktionen eines Eingabe-Vektors.
Beispiel: s = X.mean();.
Sollten Sie einmal in die Lage kommen, ein VecObj-Vektorobjekt mit einer "klassischen" C-VectorLib-Funktion verarbeiten zu wollen (z.B., um nur einen Teil zu verarbeiten), rufen Sie bitte die Member-Funktionen
getSize() für die Vektorlänge,
getVector() für den Zeiger (vom Typ tVector) oder
Pelement( n ), um einen Zeiger auf das n'te Element zu bekommen.
Fortsetzung: Kap. 4. VectorLib-Funktionen: Ein kurzer Überblick
Zurück zum VectorLib-Inhaltsverzeichnis OptiVec Home
OptiVec Home
Copyright © 1996-2020 OptiCode – Dr. Martin Sander Software Development
Letzte Aktualisierung: 5. August 2020
