Geschwindigkeitsvergleich

[irrenhaus]

Hallo,

mich würde mal interessieren, wie so eure Ausführungszeiten sind.

Einmal natürlich, um wie viel eure SSE Implementation schneller ist, als eure C Implementation (sie ist es doch hoffe ich? ).

Außerdem, wie lange eure Programme auf den Poolrechnern (direkt oder per SSH?) so brauchen, wüsste gern mal, wie sich mein Programm im Vergleich schlägt.

Interessant wäre es auch zu wissen, wie schnell die Musterlösung ist?

Ich fang einfach mal an:

Im großen Schnitt ist die SSE Lösung auf das apples.pgm Bild angewendet ca. doppelt so schnell wie die C Lösung.

Ein Beispiel:
Ticks needed for the unoptimized C-Implementation 249592075
Ticks needed for the optimized SSE-Implementation 121514522

Einer unter vielen Werten, die sind halt doch ganz gut gestreut....

Grüße
Nils

PS: Die SSE Implementation nutzt nicht die Transponierung und implementiert den vertikalen sowie den horizontalen Filter.

[mw1039]

Interessant wäre es auch zu wissen, wie schnell die Musterlösung ist?

Code: Alles auswählen

blub@clientssh1:~/gdi/build$ ./Praktikum2 ../apples.pgm 
Ticks needed for the unoptimized C-Implementation 48632900
Ticks needed for the optimized SSE-Implementation 26606127

Probier nochmal, ob dein Code auch noch kompiliert, wenn du in der CMakeLists.txt von

Code: Alles auswählen

SET(CMAKE_BUILD_TYPE "Debug")

auf

Code: Alles auswählen

SET(CMAKE_BUILD_TYPE "Release")

wechselst. Dann macht er -O3 Optimierungen.

[Tribune]

Hallo zusammen,

das Apfelbild läuft bei uns mit folgenden Ticks durch:

Ticks needed for the unoptimized C-Implementation 68324750
Ticks needed for the optimized SSE-Implementation 65220204

Beim Hauptgebäude ist die C++-Variante sogar schneller. In der SSE Variante haben wir allerdings auch mehr Schleifen.

[irrenhaus]

Interessant wäre es auch zu wissen, wie schnell die Musterlösung ist?

Code: Alles auswählen

blub@clientssh1:~/gdi/build$ ./Praktikum2 ../apples.pgm 
Ticks needed for the unoptimized C-Implementation 48632900
Ticks needed for the optimized SSE-Implementation 26606127

Probier nochmal, ob dein Code auch noch kompiliert, wenn du in der CMakeLists.txt von

Code: Alles auswählen

SET(CMAKE_BUILD_TYPE "Debug")

auf

Code: Alles auswählen

SET(CMAKE_BUILD_TYPE "Release")

wechselst. Dann macht er -O3 Optimierungen.

Habe es mal probiert, der kompiliert dann nicht mehr. Er meckert über jeden einzelnen Sprungpunkt im Inline-ASM (jeweils mit einem Error: "symbol `.sprungpunkt` is already defined").
Dann hab ichs direkt wieder umgestellt und ignoriert
Einen Tipp?

Grüße
Nils

[mw1039]

Er meckert über jeden einzelnen Sprungpunkt im Inline-ASM (jeweils mit einem Error: "symbol `.sprungpunkt` is already defined").

Hast du vielleicht Code mit Ctrl+C, Ctrl+V kopiert, der nun doppelt existiert und in der Kopie die Sprungmarken nicht umbenannt?

Ansonsten habe ich leider keinen Tipp. Die Laufzeiten sehen nicht ultra super aber ok aus. Es ist generell verdaechtig, wenn SSE-Ausfuehrungszeiten nur unwesentlich oder garnicht schneller als C-Zeiten sind.

[irrenhaus]

Hast du vielleicht Code mit Ctrl+C, Ctrl+V kopiert, der nun doppelt existiert und in der Kopie die Sprungmarken nicht umbenannt?

Ansonsten habe ich leider keinen Tipp. Die Laufzeiten sehen nicht ultra super aber ok aus. Es ist generell verdaechtig, wenn SSE-Ausfuehrungszeiten nur unwesentlich oder garnicht schneller als C-Zeiten sind.

Copy&Paste ja, aber die Sprungmarken sind umbenannt, alle sind eindeutig. Eine Idee wäre: Wir haben im Moment die zwei verschiedenen Arten von Filteranwendung (horizontal/vertikal) in C-Funktionen, die lediglich Inline-ASM enthalten. Das dient zur Übersichtlichkeit des ganzen.

Das einzige was uns einfällt, ist, dass der Compiler evtl. bei -O3 hingeht und die Funktionsaufrufe wegoptimiert, indem er den Funktionsaufruf sozusagen mit dem Funktionsinhalt ersetzt. Dabei würden die Fehler fliegen, da beide Funktionen jeweils zweimal aufgerufen werden (einmal für Ix und einmal für Iy).

Aber dass die Laufzeiten auch daran liegen kann ich mir kaum vorstellen....

Komisch ist halt schon, dass schon unsere C-Implementierung so viel länger braucht als euer Code. Die ist jetzt zwar wirklich nicht auf Effizienz getrimmt, sondern war lediglich zum verstehen, wie der Filter funktioniert, aber trotzdem....

Grüße
Nils

[skY]

Meine C Variante ist ja grausig
per SSH von Zuhause:
Fürs Hauptgebäude 650 mio bei C und für SSE ca 170mio

Äpfel: 130mio bei C und 45mio bei SSE

SSE also immer zwischen 3 und 4 mal so schnell, wobei mir noch echt viel einfällt, was man bei SSE optimieren könnte.

[mw1039]

Aber dass die Laufzeiten auch daran liegen kann ich mir kaum vorstellen....

Also ein Faktor 5 in der Laufzeit kann moeglicherweise schon aus den Optimierungen herruehren. Aber keine Gewaehr dafuer.

Komisch ist halt schon, dass schon unsere C-Implementierung so viel länger braucht als euer Code. Die ist jetzt zwar wirklich nicht auf Effizienz getrimmt, sondern war lediglich zum verstehen, wie der Filter funktioniert, aber trotzdem....

Der Musterloesungscode ist auch nicht so auf Effizienz getrimmt, weil sein Hauptzweck eigentlich ist, dass man daran das Vorgehen nachvollziehen kann.

[T.R.]

Für apples.pgm erhalte ich:

Ticks needed for the unoptimized C-Implementation 107007701
Ticks needed for the optimized SSE-Implementation 55536687

Allerdings compiliert meine Version ebenfalls nur im Debug Modus. Im Release Modus meckert der Compiler aus dem gleichen Grund, den schon ein Vorredner genannt hat. Ein Sprunglabel sei doppelt definiert.

Was kann man dagegen tun? Ich wüsste das Problem lediglich zu umgehen, indem ich die Schleife aus dem asm Block herausziehe.

[skY]

Auch wenn es etwas Offtopic ist - mir fällt eben auf, dass meine SSE Version das Bild praktisch eine Pixelreihe nach oben verschiebt, im Vergleich zum Lösungsvorschlag bzw. dem C Filter. Wird jetzt wohl nicht so schlimm sein, ansonsten sind die Bilder identisch zum Lösungsvorschlag und es fällt nur auf, wenn man eben in der Bildbetrachtung zwischen den einzelnen wechselt.

€ Das war natürlich als Frage gemeint, ob ich das doch nochmal korrigieren soll, oder es so okay ist.



€2: Wenn ich auf "Release" stelle, gibts einfach SegFaults.

[core]

Unser Code läuft ebenfalls nur unter Debug und gibt bei Release segfaults im Inlineassembler-Abschnitt.

Unsere Ausführungszeiten sind:

Code: Alles auswählen

$ w | head -1 && ./Praktikum2 Altes-hauptgebaeude.pgm
 06:07:39 up 5 days, 22:45,  5 users,  load average: 0.47, 0.33, 0.28
Ticks needed for the unoptimized C-Implementation 496538831
Ticks needed for the optimized SSE-Implementation 216915229

$ w | head -1 && ./Praktikum2 apples.pgm
 06:07:51 up 5 days, 22:45,  5 users,  load average: 0.72, 0.39, 0.30
Ticks needed for the unoptimized C-Implementation 90245405
Ticks needed for the optimized SSE-Implementation 39635469

$ w | head -1 && ./Praktikum2 Hachiko.pgm
 06:08:00 up 5 days, 22:46,  5 users,  load average: 0.84, 0.43, 0.32
Ticks needed for the unoptimized C-Implementation 33434920
Ticks needed for the optimized SSE-Implementation 14805531

Viele Grüße
core

[Thomas Huxhorn]

Ticks needed for the unoptimized C-Implementation 488355600
Ticks needed for the optimized SSE-Implementation 148347480

So langsam weil ich für jede Richtung und jeden Filter eine Doppelschleife über das Bild habe. Soll einfach das Übersetzten nach ASM fördern. Optimiert ist da null. Aber dennoch gibts ein Speedup von 3. Wenn der Code noch optimiert ist, geht SSE voll ab *g*

[simon.r]

Hallo,
unsere Zeiten sind auf ssh2:

Aktivierte Normalisierung:
Debug:
apples:
Ticks needed for the unoptimized C-Implementation 192229742
Ticks needed for the optimized SSE-Implementation 13927244
Altes_Hauptgebaeude:
Ticks needed for the unoptimized C-Implementation 1040759450
Ticks needed for the optimized SSE-Implementation 90052143

Release:
apples:
Ticks needed for the unoptimized C-Implementation 62259875
Ticks needed for the optimized SSE-Implementation 16211206
Altes_Hauptgebaeude:
Ticks needed for the unoptimized C-Implementation 316896611
Ticks needed for the optimized SSE-Implementation 88084615

Deaktivierte Normalisierung (Release):
apples:
Ticks needed for the unoptimized C-Implementation 44516195
Ticks needed for the optimized SSE-Implementation 15064286
Altes_Hauptgebaeude:
Ticks needed for the unoptimized C-Implementation 225359446
Ticks needed for the optimized SSE-Implementation 76352507

Wir hatten zwischenzeitlich auch mal Probleme mit dem Release, bis wir rausgefunden haben, dass der Compiler davon ausgeht, dass Register, die man bei der Inputdirektive angibt, sich vom Wert her nicht verändern und nach dem asm-Block einfach weiterverwendet werden können. Das haben wir gefixed, in dem wir alle Inputregister, die wir verändern, am Anfang auf den Stack pushen und nachher poppen.

[kbraden]

Hast du vielleicht Code mit Ctrl+C, Ctrl+V kopiert, der nun doppelt existiert und in der Kopie die Sprungmarken nicht umbenannt?

Copy&Paste ja, aber die Sprungmarken sind umbenannt, alle sind eindeutig. Eine Idee wäre: Wir haben im Moment die zwei verschiedenen Arten von Filteranwendung (horizontal/vertikal) in C-Funktionen, die lediglich Inline-ASM enthalten. Das dient zur Übersichtlichkeit des ganzen.

An die Sprungmarken (sowohl bei der Labeldefinition als auch bei den Jumps) "%=" haengen (als "foldVertical:" wird "foldVertical%=:") - dann werden die Sprungmarken pro "asm"-Block eindeutig und der optimizer kann die Funktionen einbetten wie er moechte.

%= wird durch eine eindeutige Zahl pro "vorkommen" des Assemblerblocks ersetzt.

LG

[ut53xuco]

Apfel:

Ticks needed for the optimized SSE-Implementation 82062653