[ASM / SSE] Vektoroperationen

[Desmulator]

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


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

[mkinzler]

Unter 64Bit ist SSE obligatorisch, da keine FPU-Befehle mehr unterstützt werden.

[Edlmann]

@mkinzler Soweit klar, deswegen sagte ich ja dass ich auch eine Variante für 64Bit Pflege - welche der Entspricht die komplett ohne assembler auskommt, und deswegen auch für Uralt PC's eingesetzt werden kann (<1999), auch wenn ich kaum glaube das so etwas noch wirklich genutzt wird und wenn, derjenige versucht darauf Spiele zu spielen ;)

[Edit]

Ist ein deklariertes Array eigentlich aligned? bzw kann man ein Array so deklarieren, dass es im Arbeitsspeicher aligned ist? Dann könnte man statt
MOVUPS ja MOVAPS benutzen (aligned Moving), welches einen weiteren Geschwindigkeitsvorteil bringen würde

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

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

Zitat von himitsu (Beitrag 1170829)

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

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

[Desmulator]

Zitat:

Zitat von Edlmann (Beitrag 1170832)

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]

Also reserviere dein Array + 15 Byte. Prüfe die Adresse, verschiebe den Pointer um addr mod 16 bytes und du hast einen richtigen Speicherbereich.