[ASM / SSE] Vektoroperationen

[Edlmann]

Werd ich mal testen, wie hoch da der Geschwindigkeitsgewinn ist...Ist allerdings in der eigentlichen Vektorbibliothek kaum umsetzbar...müsste dafür ein eigenes Array schreiben was immer aligned ist, mal schauen

[himitsu]

Zitat von 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)

Lokale Variablen sind nunmal nur 8 Bit Byte alligned.

Zitat:

Vorgabe: {$A8} {$ALIGN 8}

[edit]
Mist, hier quatscht irgendwer ständig von Bit, da hab'sch mich glatt anstecken lassen

[Edlmann]

Stimmt, sind natürlich byte...
zum alignment: Schon klar das lokale Variablen nur 8 byte-aligned sind, doch wenn ich nun vor meinem array eine Variable von 1 byte größe Deklariere, müsste doch rein Logisch das Array 8 byte weiter hinten und damit im 16-byte alignment liegen...tuts aber nicht ^^ versuch grad das ganze ohne array, nur mit pointer unt GetMem zu implementieren, denn GetMem ist ja 16 byte Aligned.

[himitsu]

Der Anfang eines statischen Arrays ist erstmal alligned, so wie es FastMM vorgibt.

Und dann kommt es auf die Größe der Felder des Arrays an.
Und bei Records (innerhalb des Arrays) auf die Größe des größten enthaltenen Feldes.

Die Felder des Arrays werden mit einem maximalen "allign" ausgerichtet, wie es {$ALIGN} vorgibt.
Die tatsächliche Ausrichtung hängt aber von den Array-Feldern ab.
Und ein PACKED ARRAY wird nie ausgerichtet.

Ein Array of Word wird "intern" mit Min(SizeOf(Word), {$ALIGN}) ausgerichtet, also mit 2, denn mehr ist sinnlos.

Oben der Record besteht aus 4 Singles und da SizeOf(Singe) nur 4 ist, wird das Array intern auch nur mit maximal 4 Byte ausgerichtet.

[Edlmann]

Vielen Dank für die Erklärung.

Habs mit 16 byte Alignment am Laufen, doch der Gewinn an Geschwindigkeit beträgt +-0... werd mir also den Aufwand damit sparen, und es bei ganz normalen Arrays lassen.

Allerdings hab ich noch immer keine alternative zu addpsh ( Vertikales aufaddieren eines MMX Registers ) gefunden, falls man nur mit SSE1 arbeiten möchte...Hat da jemand einen Plan, wie man das effizient realisieren kann? Der von mir oben vorgestellte Lösungsansatz ist nicht wirklich schneller als das ganze ohne SSE zu machen.

[himitsu]

Was mir aber noch einfällt.

Gut, die GPU mag schneller sein, als das SSE,
aber wenn nicht viel/lange gerechnet wird, lohnt es sich dann übberhaupt die GPU zu nutzen?

Schlißelich muß ja erstmal alles zu der rüber und danach dann wieder zurück.
Nicht alle GPUs unterstüzen sowas und ich glaub nicht, daß alle aktuellen GPUs eine einheitliche Schnittstelle anbieten. (is doch bestimmt schlimmer als SSE auf den verschiedenen CPUs)

[Desmulator]

Zitat von Edlmann:

Allerdings hab ich noch immer keine alternative zu addpsh ( Vertikales aufaddieren eines MMX Registers ) gefunden, falls man nur mit SSE1 arbeiten möchte...Hat da jemand einen Plan, wie man das effizient realisieren kann? Der von mir oben vorgestellte Lösungsansatz ist nicht wirklich schneller als das ganze ohne SSE zu machen.

Nein. Gibt es nicht. Genau da setzte vorhin ja meine Kritik an. Elementare Funktionen sind nicht vorhanden. Es gibt auch keinen wirklich sinnvollen Umweg. Entweder man macht es per Hand mit der FPU oder man sortiert aufwendig irgendwelche einzellnen Singles umher. Ob das SSE 1.0 überhaupt kann weiß ich jedoch nicht.

http://softpixel.com/~cwright/programming/simd/sse.php

Zitat:

Gut, die GPU mag schneller sein, als das SSE,
aber wenn nicht viel/lange gerechnet wird, lohnt es sich dann übberhaupt die GPU zu nutzen?

Lohnt es sich dann, sich in SSE einzuarbeiten oder reicht die heutzutage durchaus schnelle Pipeline der normalen CPU/FPU?

[Edlmann]

Ja, das hin und herschieben geht, mit SHUFPS, ist schon seit SSE1 dabei - Der Ansatz fürs Kreuzprodukt den ich weiter oben gepostet hatte benutzt das ganze auch.

[Desmulator]

shufps bringt dir garnichts. Damit kannst du nur die Reihenfolge innerhalb ändern. Aber du musst alle in einer Zeile addieren. Eigentlich müssten alle aus der ersten Zeile in die erste Spalte geschoben werden, alle aus der zweiten Zeile in die zweite Spalte usw. Dann könntest du addieren, aber das ist afaik nicht möglich.

[Edlmann]

Naja, es ginge, allerdings bräuchte man 4 Register. Das 1ste bleibt wies ist, beim 2. Packst du das 2. Element an 1. Stelle mit shufps, beim 3. das 3., beim 4. das 4., und 3 additionen später hätte man das Ergebnis an der 1sten Stelle des StartRegisters (wenn man all die geshuffelten Register aufs Startregister addiert). Wär aber sowas von umständlich.

[Edit]

Was mir noch fehlt ist ein wenig Dokumentation zu System.TestSSE...weiß jemand von euch was die weiteren Bits davon bedeuten? Auf meinem i5-760 mit SSE bis zu 4.2 enthält TestSSE 127, der einzige KOmmentar dazu sagt jedoch dass nur Bits 1 und 2 Bedeutung hätten...1 für SSE 1, 2 für SSE2...

[Edit 2]

Okey, TestSSE macht nichts anderes, als die CPUID bits auszulesen, wobei hier das 25. Bit für SSE und das 26. für SSE2 steht. Anscheinend gibt es keine wirkliche Möglichkeit, SSE3 Unterstützung auszulesen