[ASM / SSE] Vektoroperationen

[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:

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:

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:

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

[Edlmann]

Scheint 8 bit Aligned zu sein...Addr(Vecs) mod 16 ist immer 8, Egal an welcher Stelle es deklariert wird (zumindest wenn es ein dynamisches Array ist, festes Array ist gar 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:

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...