[ASM / SSE] Vektoroperationen

**Desmulator**

Eigentlich macht man solche Array-Operationen über ESI (Source), EDI (Destination) und ECX (Counter).
z.B. wenn du dir Funktionen wie Copy/Move oder Pos ansiehst.
Und eigentlich gibt es spezielle Registerzugriffe, damit man mit nur einem Zähler als Offset für beide/alle Arrays auskommt.

Wobei einige Register spezielle Sonderfunktionen besitzen und oder welche sich für bestimmte Dinge bei Vielen eingebürgert haben.
Eben EBX als Zwischenspeicher für den Stack
ECX für Zähler
oder ESI und EDI für Arrays

Jetzt hast du aber was verwechselt. Wir machen das mit den Registern jetzt nochmal ganz von vorne.
Es gibt bei x86-kompatiblen Prozessoren 8 große Register, übernommen vom 8086, damals noch 16-bit.
Vier dieser 8 Register lassen sich unterteilen in den hohen und tiefen Teil, woduch erneut 8 8-Bit Register dargestellt werden.
Jedes dieser Register hat einen speziellen, seine Funktion zugehörigen Name.
Der hohe Teil wird immer durch ein h-Suffix und der tiefe Teil durch ein l-Suffix gekennzeichnet. Beide Teile zusammen bilden
dann das 16-Bit Register, dass x als Suffix besitzt.

ax[ah:al]: Akkumulator, damals als Zielregister für die meisten Rechenoperationen.
bx[bh:bl]: Base, wurde früher von BIOS-Routinen genutzt um zusammen mit dem es-Segment ein Offset, eine Basis, zubilden,
an der Daten von der Festplatte in den Speicher geladen wurden. ( hat nichts mit dem Stack zu tun )
cx[ch:cl]: Counter, für loop-, jcxnz- und rep-Instruktionen.
dx[dh:dl]: Data, fürs Speichern von anderen Werten, das Allzeckregister. Wird auch von mul und div genutzt.

Die folgenden Register können nicht unterteilt werden und haben ganz spezielle Funktionen.

di : Destination Index, Zeiger für String-Operationen.
si : Source Index, Zeiger für String-Operationen.
sp : Stack Pointer, Zeiger für den Stack, wird bei jedem push vekleinert, bei jedem pop vergrößert.
bp : Base Pointer. Das ist nun wirklich mit das wichtigste Register überhaupt. Wenn eine Funktion ihrer Parameter über den Stack übergeben bekommt, dann kann sie,
wenn sie bp = sp setzt, alle Parameter ab dem Offset [ebp+0x08] ( in 32-bit ) erreichen, und Platz für ihre internen Variablen kann sie via sub esp, size reservieren.
Diese sind dann ab [ebp-0x04] erreichbar. Cool oder?

Aber das sind doch alles nur 16-bit Register, wir arbeiten doch mit 32-bit? Richtig, darum packt man auch im Protected Mode des x86 einfach ein e vor das Register, wie extended
und man erhält die bekannten Register eax, ebx, ecx, edx, edi, esi, esp, ebp. Die oberen 16-Bit der Register sind übrigens nicht direkt adressierbar.

Welche Register darf eine Funktion nun benutzen? Alle. Allerdings nicht einfach so. Es gibt die sogenannten GPR ( General Purpose Register ), namentlich genannt sind das
eax, ecx und edx, diese darf eine Funktion frei verändern und muss nicht garantieren, dass sie nach dem Funktionsaufruf ihren Wert behalten. Die anderen Register müssen dagegen erst vor dem Gebrauch geschützt werden.

markieren

Code:

			MOV ESI, &Quelle // Byte-Arrays

MOV EDI, &Ziel

MOV ECX, &Anzahl

@1:

MOV AL, [ESI]

MOV [EDI], AL

INC ESI

INC EDI

DEC ECX

JNZ @1

Dieser Code ist so eher uncool. Wenn man die Register und ihre Funktionen wirklich nutzen möchte, dann sollte man mit die Stringfunktionen nutzen ( movs, stos, lods, cmps usw. )
um die Register EDI und ESI einzubrigen und das rep-Prefix mit all seinen Variationen. ( rep, repne, repnz, .. )

markieren

Code:

			mov edi, Ziel

mov esi, Quelle

mov ecx, Anzahl

rep movsb

Fertig. Jetzt schauen wir uns das mal an.

markieren

Code:

rep movsb ; 3 + Anzahl Clocks, 2 Byte

benötigt ( 3 + Anzahl ) Clocks um fertig zu werden. Die zu dekodierenden Bytes sind zwei. Einmalig.
Dagegen den anderen Code.

markieren

Code:

			MOV AL, [ESI] ; 1 Clock, 2 Byte

MOV [EDI], AL ; 1 Clock, 2 Byte

INC ESI       ; 1 Clock, 1 Byte

INC EDI       ; 1 Clock, 1 Byte

DEC ECX       ; 1 Clock, 1 Byte

JNZ @1        ; 1 Clock, 2 Byte

Ein einziges Byte zu kopieren benötigt also nun 6 Clocks und 9 Bytes die dekodiert werden müssen.
Bedeutet also im Vergleich:

Mit rep movsb:
Clocks: 3 + Anzahl, Bytes: 2
Ohne rep movsb:
Clocks: 6 * Anzahl, Bytes: 9 * Anzahl
Man muss kein Profi sein um zu erkennen, dass das rein haut.

Den Unterschied nennt man CISC und RISC.
rep mosvb ist ein Befehl wie man ihn eher bei den Complex Instruction Sets finden würde.
Deine Variante ist die eines RISC, der diese allerdings wesentlich schneller ausführen kann, da seine Pipeline nicht derart komplex gestaltet ist.

Und was ist der heute Prozessor für einer? Schaut man sich die Adressierungsmöglichkeiten usw. an, ist er ganz klar ein CISC. Auch mit den Erweiterungen wie SSE, 3D!Now und das ganze Zeug macht er einen weiten Schritt auf das Modell des Complex Instruction Set. Dazu gehört auch die loop-Instruktion. Sie übernimmt mehrer Vorgänge auf einmal.
Das war früher praktisch, da die Prozessoren langsamer waren und so ein Befehl Geschwindigkeit brachte.

Zitat von himitsu:

LOOP selber ist aber nicht unbedingt ein schneller Befehl (keine Ahnung warum),
da ist

markieren

Code:

DEC ECX

und

markieren

Code:

JNZ @1

dann doch etwas besser.
Aber LOOP zeigt die Spezialisierung von Registern sehr gut.

Warum ist loop nun langsamer? Die heutigen Prozessoren tendieren wieder zum RISC, also dem Reduced Instruction Set. Sie können einfach Befehle extrem schnell ausführen. Intel und AMD arbeiten stark an ihrern Pipelines um auch die letzte Picosekunde raus zu kitzeln. loop ist ein Artefakt aus den alten Zeiten und wird nicht mehr wirklich gepflegt. Mit so einem Prozessor ist es wie mit eine API die sich in Entwicklung befindet. Alte Funktionen bleiben erhalten, werden aber nicht mehr verbessert oder angepasst, weil man ein neues Modell verfolgt.

Der Vollständigkeit halber:

markieren

Code:

			MOV ESI, &Quelle

MOV EDI, &Ziel

MOV ECX, &Anzahl

@1:

MOV AL, [ESI + ECX] ; 1 Clock, 3 Byte

MOV [EDI + ECX], AL ; 1 Clock, 3 Byte

LOOP @1             ; wenn ECX = 0, 2 Byte

                    ;    5 Clock sonst 6 Clock

Clocks: ( 7 * Anzahl ) + 1, Bytes: 8 * Anzahl

Jetzt wundert man sich warum SSE nicht wirklich schneller ist als die normalen Funktionen.
SSE wurde 1999 entwickelt. Natürlich auch verbessert und vieles mehr. Doch kaum einer nutzt es. Das weiß auch Intel und AMD. Diese setzen also nun mehr darauf die "alltäglichen" Instruktionen zu verschnellern als solche speziellen. Es muss ja auch Medienwirksam sein. Wen interessiert ein Benchmarktest von SSE 3.0? Niemanden wirklich. Wenn es aber heißt, Befehle werden 150% schneller ausgeführt und man ein kleines Programm mit den üblichen Befehlen sieht ( mov, cmp, test, shl, shr usw. ) dann wird man hellhörig.
Wie der Threadersteller außerdem selbst sicherlich festgestellt hat ist SSE garnicht mal so leicht zu lernen und zu verstehen. Informationen sind nur sperrlich vorhanden und wirklich nützliche Funktionen sind auch nicht dabei. Das Kreuzprodukt ist immer noch ein riesiger Klotz. Lassen viele Firmen die Finger davon. Dazu kommt noch, dass man sich fast nie sicher sein kann, dass jeder Prozessor die entsprechende SSE-Version unterstüzt und bevor man 5 Versionen des selben Programms schreibt, nur um SSE best möglich zu verwenden und das letzte Quäntchen aus der Rechenleistung herraus zukitzeln, wartet man lieber bis Intel oder AMD die normalen Befehle beschleunigen, wo man sich sicher sein kann, das jeder x86 die versteht. Isso.

Die Prozessorhersteller lassen sich auch immer wieder irgendwas neues einfallen, irgendwelche speziellen Instruktionen, die richtig angewand, durch aus ordentlich geschwindigkeit bringen können. Aber kaum ein Mensch hat Lust sich in dem ganzen Wust an Befehlen, die besten für sein Problem herraus zu suchen.

Beispiel-Bild.

Der Grund warum es nicht der burner ist, sind die Umstände. Und die richtige Anwendung.

SSE steht für Streaming SIMD Extensions. Und SIMD nochmal genau für Single Instruction, Multiple Data.
Der Zweck von SSE ist möglichst viele Daten gleichzeitig zu verarbeiten.
Dumm nur, dass die meiste Zeit mit dem Laden von Werten aus Register oder Speicher verbraten wird.
Da bringt auch die Parallelisierung von vier Gleitkommazahlen nichts. Die Grafikkarte berechnet mit 18000 Pixelshadern gleichzeit deutlich mehr.

Das ist das nächste Problem von SSE und MMX usw. Sie wurden auf den Prozessor oben aufgesetzt. Sie haben ewig lange Instruktionen. 4-Byte und mehr. Das braucht alles bis es decodiert ist. Dann noch die entsprechenden Daten laden. Die Pipeline wechseln usw. Netto kommt da nicht viel Zeit bei rum.

Seien es Vektoren oder wie bei MMX Ganzzahlen ( dieses wurde wie der Name ( Multi Media Extension ) sagt, für Farben und Sättigungsrechnung ausgelegt. )
Dabei reden wir aber jetzt nicht von 5 Vektoren sondern von 1310720 Pixeln oder doppelt so vielen Vertices die berechnet werden wollen.
Jetzt wird einer sagen, wieso, dafür ist doch die Grafikkarte zuständig. Ja. Ist sie auch.

Und darum ist SSE auch so sehr mit Vorsicht zu genießen. Wir haben einen Prozessor der einfache Berechnungen ausführen soll, hauptsächlich aber die Maschine steuert und einzellnen Modulen, wie der Grafikkarte, die explizit für ihre Funktion ausgelegt sind, Anweisungen gibt.

SSE ist der Versuch einen allzweck-Prozessor zu bauen. Hat nicht geklappt. CISC ist nicht das ware, da es immer aufgeblähter werden muss um mit zu halten, weil es immer nur ganz spezielle Befehle gibt für spezielle Dinge. RISC ist wieder im kommen. SSE ist aber nicht RISC.

Zitat:

CPUs mit CISC-Befehlssatz waren lange Zeit mikroprogrammiert. Heute findet man kaum noch mikroprogrammierte CISC-CPUs. Ab dem Pentium Pro verfügen die Intel-Prozessoren über eine vorgeschaltete Funktionseinheit, die die komplexen Befehle in RISC-Befehle übersetzt. Je nach Hersteller und CPU werden diese Einheiten ROP, Micro-Op oder µOp genannt. Weitere Beispiele für CPUs mit CISC-Befehlssatz sind der Intel 8086, der Intel 80386, der Motorola 68000, der Zilog Z80 und die CPUs der System z-Reihe von IBM.

Der Beitrag über SSE ist noch lange nicht fertig und ich könnte noch ewig schreiben, aber langsam bekomme ich hunger. Bau dein SSE ein, es ist wirklich cool, aber erhoffe dir jetzt nicht zu viel. SSE ist nicht ausgereift. Ahja nächster Punkt. SSE wurde erfunden um was neues zu schaffen, wir verkaufen Prozessoren mit SSE. Hört sich super an, kein Endanwender weiß, was es ist, kein Programm nutzt es, da neue Technik immer neue Programm erfordert nicht alle Computer direkt SSE besitzen, aber man kauft es trotzdem. Intel und AMD haben was sie wollen. Geld und eine verkümmerter Versuch was gutes zu machen.

Davon mal abgesehen, du hast bei deinem Beispiel 9000 Zyklen weniger. Was erwartest du denn?

Edit:

http://www.bernd-leitenberger.de/cisc-risc.shtml super artikel zu CISC und RISC

**Edlmann**

Mittlerweile sind es durch die kleinen aber feinen Optimierungen von Himitsu sogar 20.000 Zykel - und damit bin ich ziemlich zufrieden

Vielen Dank für deine Erklärung zu SSE, hat echt ein paar Fragen geklärt. Allerdings hab ich SSE schon an mehreren Stellen im Einsatz gefunden - an der selben
Stelle an der ich auch im Moment arbeite, 3D-Mathematik, die ja Hauptsächlich in Spielen eingesetzt wird. z.B. die Doom-3-Engine, hat für eigentlich alle damaligen
Befehlssätze einen eigenen Prozessor implementiert (ist natürlich kein Prozessor, hat idSoftware so getauft) - also 3D!Now, MMX, SSE, SSE2, SSE3 und 'AltiVec' (hatte ich vorher noch nie von gehört). Es kann natürlich sein dass der Trend mittlerweile davon abgerückt ist - doom ist ja nicht mehr das neusete, doch es bringt ja noch immer einiges an Performancegewinn (50% bei Arrays)...Und da das ganze heute eigentlich jeder Prozessor unterstützt, und auch auf jedem einen - mehr oder weniger großen - Performancegewinn bringt, werd ich auch jeden Fall teilweise darauf zurückgreifen, um die Zeitkritischsten Sachen zu beschleunigen.

Wird zwar einiges an Zeit dauern bis ich alle operationen so hab wie ich will, aber ists auch für den Lernfaktor wert

Und so extrem unübersichtlich sind auch erweiterte Algorithmen nicht imho...das Kreuzprodukt kann ja berechnet werden durch:

markieren

Code:

			        __asm

        {

                MOV EAX Op_A                               // Load pointers into CPU regs

                MOV EBX, Op_B

                MOVUPS XMM0, [EAX]                 // Move unaligned vectors to SSE regs

                MOVUPS XMM1, [EBX]   

                MOVAPS XMM2, XMM0               // Make a copy of vector A

                MOVAPS XMM3, XMM1               // Make a copy of vector B

                SHUFPS XMM0, XMM0, 0xD8      // 11 01 10 00  Flip the middle elements of A

                SHUFPS XMM1, XMM1, 0xE1       // 11 10 00 01 Flip first two elements of B

                MULPS  XMM0, XMM1                 // Multiply the modified register vectors

                SHUFPS XMM2, XMM2, 0xE1      // 11 10 00 01 Flip first two elements of the A copy

                SHUFPS XMM3, XMM3, 0xD8     // 11 01 10 00  Flip the middle elements of the B copy

                MULPS XMM2, XMM3                 // Multiply the modified register vectors

                SUBPS  XMM0, XMM2                  // Subtract the two resulting register vectors

                MOVUPS [Ret_Vector], XMM0      // Save the return vector

        }

(Nicht meine Implementierung, an der Delphi Version feil ich noch)

Was zwar nicht wenig ist, aber merklich schneller läuft als der vom Compiler erzeugte Source

Was mich besonders fasziniert ist, dass es immer noch um 5-6000 Zykel schneller ist, einen 4D-Vector per SSE zu berechnen,
als einen 3D-Vector mit normalem Delphi Source...Und das auf einer relativ aktuellen CPU - Welche ja wenn ich das richtig verstanden habe
nicht so wirklich auf SSE setzen / wo SSE nicht so optimiert ist wie es sein könnte. Auf älteren CPU's müsste dann ja das ganze noch mehr Performance einbringen,
oder nicht?

**Medium**

@Desmulator:

Spiele rücken allerdings auch immer mehr von den SIMD ab, und die "Numbercruncher" in Rechenzentren auch zunehmend. Grund dafür ist wohl, dass die Grafikchips immer universeller wurden (was früher noch eine T&L Einheit war, ist heute dank OpenCL und CUDA fast vollwertig programmierbar). Gerade bei Spielen ist ausser der Grafik und Physik (NVidia PhysiX läuft auch auf hauptsächlich der GPU, wenn diese das kann) nicht mehr so arg viele Einsatzstellen gegeben. GPUs geben einfach ZU gute Streaming Vector Prozessoren ab - so gut, dass die Architektur glaube ich mittlerweile auch stark in Clustern genutzt wird. (Siehe NVidia Tesla Serie.)

Wirklich intensiven Gebrauch vom SIMD machen mittlerweile glaube ich nur noch Videode- und Encoder, der Rest dürfte sich als Einzelfälle auffassen lassen. Wo ich aber zustimme: Die zu lernen macht irgendwie trotzdem Spaß

(Und ein Gewinn ist ja da!)

**Edlmann**

Da das Projekt an dem ich arbeite kein Tripl-A Titel werden soll, sondern nur ein kleines Spiel mit ner schön anzuschauenden
3D-Grafik, und es mir hauptsächlich um den Lerneffekt geht (hab z.B. schon ne Konsole implementiert, mit ConsoleVar/Command-System, oder den
Flocking Algorithmus von Craig Reynold zur Gegnerbewegung), bringt das hier einiges an Performancegewinn

Hab nicht vor mich in PhysX / Cuda einzuarbeiten...
Dafür fühl ich mich in normalem Delphi zu wohl ;D

**himitsu**

FastMM erstellt und unterteilt seine Speicherblöcke aligned (ich glaub aktuell alle 16 Byte)
dynamische Arrays und alles über GetMem ist somit ordentlich ausgerichtet.

Der Stack ist auch möglist auf 4 Byte ausgerichtet (falls da keiner Mist baut)

Zitat:

und einzellnen Modulen, wie der Grafikkarte, die explizit für ihre Funktion ausgelegt sind,

Wobei man ja seit einer ganzen Weile damit anfängt Code, welcher mal in der CPU berechnet wurde, in die schnellere/bessere GPU auszulagern. (vorallem für Ver/Entschlüsselungen und das Hacken von sowas)

Zitat:

Der momentane Trend, die Grafikprozessoren mit ihrer Rechenleistung allgemein zugänglicher zu machen ist imo der richtige

Wobei eben nicht alles was da gerechnet wird, mit was Graphischem zu tun hat.

**Edlmann**

Aber wenn dynamische Arrays 16 bit Aligned sind müsste doch folgender Code möglich sein:

markieren

Delphi-Quellcode:

			function AddVecsSSE(const av1, av2: TTestVec): TTestVec;

asm

  MOVAPS XMM0, DQWORD PTR [&av1]

  MOVAPS XMM1, DQWORD PTR [&av2]

  ADDPS XMM0, XMM1

  MOVUPS DQWORD PTR [&Result], XMM0

end;

Er führt allerdings zu einer Zugriffsverletzung...

**Desmulator**

Zitat von Edlmann:

Aber wenn dynamische Arrays 16 bit Aligned sind müsste doch folgender Code möglich sein:

markieren

Delphi-Quellcode:

			function AddVecsSSE(const av1, av2: TTestVec): TTestVec;

asm

  MOVAPS XMM0, DQWORD PTR [&av1]

  MOVAPS XMM1, DQWORD PTR [&av2]

  ADDPS XMM0, XMM1

  MOVUPS DQWORD PTR [&Result], XMM0

end;

Er führt allerdings zu einer Zugriffsverletzung...

Überprüfs doch einfach, lass dir die Adresse von av1 ausgeben und wenn mod 16 != 0 dann ist es nicht aligned

**Desmulator**

Zitat von himitsu:

Zitat:

und einzellnen Modulen, wie der Grafikkarte, die explizit für ihre Funktion ausgelegt sind,

Wobei man ja seit einer ganzen Weile damit anfängt Code, welcher mal in der CPU berechnet wurde, in die schnellere/bessere GPU auszulagern. (vorallem für Ver/Entschlüsselungen und das Hacken von sowas)

Zitat:

Der momentane Trend, die Grafikprozessoren mit ihrer Rechenleistung allgemein zugänglicher zu machen ist imo der richtige

Wobei eben nicht alles was da gerechnet wird, mit was Graphischem zu tun hat.

Das sind jetzt Wortspielereien, bloß weil es Grafikkarte heißt. Das "Ding" ist dafür ausgelegt, Datenmassen in kurzer Zeit durch zu schleusen und zu verrechnen, warum also diese Möglichkeit nicht nutzen? Ob der Pixelshader, der nur aus historischen Gründen so heißt, jetzt einen Farbwert berechnet oder ein Byte dekodiert, das ist sowohl dem Pixelshader als auch mit egal. Wenn man es so genau nehmen will, dann sollte der Keyboard Chip von früher auch direkt umbenannt werden müssen, seitdem man damit die 21. Adressleitung frei schaltet zu Keyboard und Memory Size Chip. Für Grafikkarten würde sich das aber cool an hören Massiv Data Streaming Board

**Desmulator**

Persönliche Meinung & Erfahrung
Was ich jetzt sage, kann mir vielleicht den Kopf kosten, aber naja

SSE 3.0 wurde 2004 auf den Markt gebracht. Wenn du also in kauf nimmst, dass ca. 30% der Anwender dein Programm nicht nutzen können, kannst du SSE 3.0 benutzen.
Ansonsten nutze SSE 1.0, das ist verlässlich auf allen Platformen vorhanden. Jedoch fehlen elementare Funktionen.

Schonmal über eine parallelisierte Matrixmultiplikation nachgedacht. Klappt mit SSE eigentlich super, Matrixzeilen spalten, Vektor laden, Vektor 3 mal kopieren, mit jeder Spalte
multiplizieren, ja und dann wirds schwer. SSE erlaubt einem nicht, eine Zeile zusammen zu addieren. addpsh gibts erst bei SSE 3.0 und das nervt.
Welchen Zweck erfüllt mir SSE wenn ich nach dem multiplizieren wieder alles rausladen muss und selbst zusammen addieren darf.
Auch wenn wir von CISC und RISC geredet haben und ich eigentlich mehr der RISC-Fan bin. Wenn man sowas schon wirklich machen muss, solche Erweiterungen, die nun einfach dafür ausgelegt sind, 3D-Anwendungen zu beschleunigen, sollten direkt Befehle wie Kreutzprodukt oder Matrixmultiplikation einbauen, die benötigt werden. Außerdem sollte es batch-Funktionen geben und nicht per Hand jeder einzellne Vektor geladen werden müssen, ähnlich meinem rep movsb beispiel. Wenn muss ich denn mal einen einzellnen Vektor verrechnen? Und das ganze soll dann noch so zeitkritisch sein, dass mit die normale FPU nicht reicht? Also da hört's auf.

Das Ganze könnte doch so aussehen:

markieren

Code:

			mov edx, &matrix

mov esi, vertexArray

mov ecx, length(vertexArray)

rep mulMatPS

Kein Befehl muss mehr dekodiert werden und in einem Rutsch rechnet er einem alles durch. Das was man auch wirklich braucht. Und dafür gibt's ne Grafikkarte die genau DAS macht.
SSE ist ein Denkfehler mit Designfehler. Der momentane Trend, die Grafikprozessoren mit ihrer Rechenleistung allgemein zugänglicher zu machen ist imo der richtige. Wozu habe ich 1000 Shader auf der Platine wenn ich sie nur für's Bildchen-Malen nutzen kann, obwohl sie wesentlich mehr können?

Zitat:

Was mich besonders fasziniert ist, dass es immer noch um 5-6000 Zykel schneller ist, einen 4D-Vector per SSE zu berechnen,
als einen 3D-Vector mit normalem Delphi Source...Und das auf einer relativ aktuellen CPU - Welche ja wenn ich das richtig verstanden habe
nicht so wirklich auf SSE setzen / wo SSE nicht so optimiert ist wie es sein könnte.

Grund dafür ist die Architektur. Delphi nutzt die FPU. Heißt also einen Werte laden, Rechnen, zurück schreibe, nächsten Wert laden ...
Bei SSE ist der Vorteil eben klar, du lädst direkt alle vier Werte gleichzeitig, die berechnest alle vier gleichzeitig und du schreibst sie auch gleichzeitig wieder zurück.
Bei heutiger Hardware ist es defactor kein Unterschied ob du einen oder vier Werte in den RAM packst. Jede mal neu die Adresse zu laden braucht dagegen mehr Zeit.

Zitat:

Auf älteren CPU's müsste dann ja das ganze noch mehr Performance einbringen,
oder nicht?

SSE wächst natürlich mit. Es werden nicht die gleichen Bausteine wie 1999 verwendet, der Prozessor taktet schneller. Ich denke der Gewinn wird sogar noch geringer sein, da sie viel an der normalen Pipeline geändert hat.

**Edlmann**

Auf das Problem dass man mit SSE1 noch kein MMX-Register aufaddieren kann bin ich auch gerade gestoßen...ist echt ziemlich nervig...

Man könnte natürlich 2 Varianten schreiben - eine für SSE 3.0 und eine für SSE 1 - dann wäre ich allerdings für diese Prozeduren bei 3 verschiedenen Varianten die implementiert werden müssen...Normal für 64 Bit-Compiler (falls ich mal auf die Idee komme den zu nutzen), SSE1 und SSE3...und wie findet man heraus welches SSE von der CPU unterstützt wird?
Ob SSE generell möglich ist lässt sich ja über das 25.? oder so Bit der CPUInfo abfragen...bzw über System.TestSSE, aber TestSSE unterscheidet nach dokumentation nur zwischen SSE1 und SSE2...