Seite 1 von 2

Performance

Verfasst: 27. Jan 2012 00:56
von Lucas-
Würde mich mal interessieren wie hoch der speed-up zwischen GPU/reiner CPU Variante bei anderen Gruppen auf den cluster-Rechnern ist.

Bei uns liegt er bei ~13, aber ich bin mir sicher, da ist noch einiges möglich :idea:

Re: Performance

Verfasst: 27. Jan 2012 10:17
von mw1039
Also zumindest mit CUDA ist (auf test.fasta) mindestens 65-fach moeglich. Schwer zu sagen was mit OpenCL moeglich ist.

Re: Performance

Verfasst: 27. Jan 2012 10:29
von kbraden
Wir haben den CPU-Algorithmus mehr oder weniger 1:1 portiert und sind auch so bei eurer Groessenordnung.

Re: Performance

Verfasst: 27. Jan 2012 13:42
von mw1039
Fuer das Testat ist es natuerlich nicht erforderlich noch schneller zu sein, aber falls ihr es mal versuchen wollt:
Wenn man jede Workgroup \(\Delta_i\cdot\Delta_j\) Matrixeintraege berechnen laesst (statt nur einem), kann man den lokalen Speicher sinnvoll einsetzen: Dann macht es Sinn alle betroffenen Sequenzspalten (\(\Delta_i+\Delta_j\) Spalten) von global nach lokal zu kopieren und in der Berechnung immer aus der Kopie zu lesen.

Re: Performance

Verfasst: 27. Jan 2012 14:06
von fbussjor
Auch zum Thema Performance:
Ist mit der reine CPU-Implementation die Ausführung mit -oclcpu oder -cpu gemeint?

Re: Performance

Verfasst: 27. Jan 2012 14:23
von mw1039
Die mit -cpu. Die hat keinen OpenCL-Overhead. Deswegen "rein".

Re: Performance

Verfasst: 27. Jan 2012 14:43
von Narida
Bei mir 57ms bei test.fasta auf dem Cluster.. das entspricht einem Speedup von ca. 20...

Re: Performance

Verfasst: 27. Jan 2012 15:15
von mw1039
Uebrigens koennt ihr mit dem Visual Profiler (liegt unter /usr/local/cuda/computeprof/bin/computeprof) analysieren, wo bei eurem Programm etwaige Flaschenhaelse liegen.

Re: Performance

Verfasst: 30. Jan 2012 17:28
von ThorbenKo
Hmm. also in den Bereichen in den Ihr seid bin ich bei weiten nicht, momentan sieht es so aus:

Bei mir Lokal 4 facher speedup
RGB: 2 facher Speedup (ca)

aber nun kommst:

Cluster 10% LANGSAMER.

Weiß jemand wie das sein kann? Dachte vll liegt es an der Auslastung der GPU auf dem Cluster, aber den bekomme ich mit htop entweder nicht angezeigt, oder er ist doch nicht das Problem.

*ratlos*

Re: Performance

Verfasst: 30. Jan 2012 20:43
von simon.r
Ohne weiteres ist es wahrscheinlich nicht so einfach auf den Grund für deine langsamere Laufzeit zu schließen; hast du mal andere Größen für die Workgroups probiert? Der Speedup unserer Lösung ist auf dem Cluster deutlich höher als auf meinem Rechner und bewegt sich ebenfalls in den hier genannten Größenordnungen (24 bzw. 7 bei LOOPCOUNT=100).

Re: Performance

Verfasst: 30. Jan 2012 20:53
von mw1039
ThorbenKo hat geschrieben:RGB: 2 facher Speedup (ca)
Bist du per SSH da drauf gewesen? Weil dann solltest du eigentlich nur einen Kern sehen. Dann koennte ich mir diesen Speedup nicht vorstellen.
ThorbenKo hat geschrieben:Cluster 10% LANGSAMER.
Wie parallelisierst du den aktuell? Wie in der Codevorgabe - eine Workgroup arbeitet an einem Matrixeintrag und 25 Threads innerhalb einer Workgroup?
Ich koennte mir vorstellen, dass du irgendwie nicht feingranular genug parallelisiert hast. Die GPU hat SIMD-Einheiten (sog. Multiprozessoren), die immer gleichzeitig 16 oder 32 Threads ausfuehrt, solange diese die selben Codezeilen ausfuehren. Wenn du irgendwie so parallelisierst, dass alle Threads etwas anderes tun (weil z.B. alle in einem if unterschiedliche Abzweigungen nehmen), wird die Threadabarbeitung sequentialisiert und das Ergebnis kann durchaus langsamer als die CPU-Referenz sein.
Wichtig ist auch, dass man moeglichst wenig Zugriffe in den globalen Speicher hat und moeglichst viele Rechenoperationen im Vergleich zu Speicherzugriffen. Dann kann die GPU naemlich das Warten auf Speicheranfragen mit anderen Berechnungen ueberbruecken.

Re: Performance

Verfasst: 30. Jan 2012 20:59
von mw1039
Achso, hab noch was vergessen.
ThorbenKo hat geschrieben:Dachte vll liegt es an der Auslastung der GPU auf dem Cluster
Daran sollte es eigentlich nicht liegen. Falls noch andere Studenten gerade zusammen mit dir auf einem Rechner sind, dauern deren Berechnungen auch nur Sekundenbruchteile. Ausserdem hat jeder Rechner mehrere Karten und du solltest eigentlich, wenn eine belegt ist, eine andere zugeteilt bekommen.

Aber pruef mal bitte, ob du vielleicht auf teachnode07 warst. Uns hat jemand gemailt, dass es mit diesem Rechner Probleme zu geben scheint. Wir untersuchen das morgen.

Re: Performance

Verfasst: 31. Jan 2012 15:16
von ThorbenKo
Ja war ich. Habe den exact gleichen Code nun auf dem teachnode05 getestet und mit loop 100:

CPU 10969 millisec
OCLGPU 2392 millisec.


Ich arbeite nur mit einem thread pro Workgroup.

Ist das erlaubt? Ich denke schon, weil es steht ja nichts in der Aufgabe wie es gelösst werden soll.

Ich weiß durch mehr Treads pro WOrkgroup wäre mir drin, aber mir würde das so reichen ;)

LG Thorben

Re: Performance

Verfasst: 31. Jan 2012 16:38
von Lucas-
ThorbenKo hat geschrieben:Ja war ich. Habe den exact gleichen Code nun auf dem teachnode05 getestet und mit loop 100:

CPU 10969 millisec
OCLGPU 2392 millisec.
Was sind das jetzt für Zeiten? 100 Loops können das irgendwie nicht sein, da die reine cpu variante da so 100*1250 ms braucht.

Also bei uns läuft der code auf dem cluster inzwischen in ca. 38 ms. Der Hauptgrund dafür ist, dass wir die workgroups größer gemacht haben und damit viel näher an die 768 Threads kommen, die max. gleichzeitig ausgeführt werden können.

Re: Performance

Verfasst: 31. Jan 2012 16:42
von ThorbenKo
Du hast natürlich recht.

Sorry ich meinte loop 10.

aber netter Speedup bei euch ;)

EDIT: das du aller dings sagst die CPU variante braucht 1250 ms irritiert mich, ich werde mal schauen ob ich noch irgendwelche änderungen in der CPU Version gemacht habe (das habe ich) aber nicht wieder ausgebaut.

EDIT2: nee die CPU version ist die Orginalversion. Gibt wohl kleine Abweichnungen zwischen den verschiedenen Teachnode oder so ;)