Seite 1 von 2

SpeedUp

Verfasst: 19. Dez 2011 14:31
von studentabc
Wie genau hängt der SpeedUp mit der Zeit zusammen?
Angenommen ich hätte 4 Prozessoren, nach der Aufgabenstellung brauche ich nun einen SpeedUp von 2 um die volle Punktzahl im Praktikum zu bekommen. Darf das Programm nun insgesamt die Hälfte der Zeit oder darf es sogar nur 1/3 der Zeit benötigen.

Re: SpeedUp

Verfasst: 19. Dez 2011 14:45
von mw1039
Der Speedup ist der Quotient aus sequentieller und paralleler Programmlaufzeit. Du darfst also nur die Haelfte der Zeit benoetigen. Pass aber auf, dass dein Programm skalieren muss. Aktuell ist der Cluster noch nicht von aussen erreichbar, aber wenn er es ist, brauchst du bei 24 Kernen einen Speedup von 12.

Re: SpeedUp

Verfasst: 20. Dez 2011 18:32
von badvirt
Dahinter steckt aber die Annahme, dass die praktisch verfügbare Rechenressourcen auch linear mit der Anzahl der Kerne skalieren. Ist es wirklich so?

Re: SpeedUp

Verfasst: 21. Dez 2011 00:27
von mw1039
Nein, in der Praxis nicht.

Re: SpeedUp

Verfasst: 22. Dez 2011 12:47
von badvirt
Deswegen würde auch der relative Speedup mit steigender Anzahl der Kerne immer kleiner werden. Sprich es wäre schwieriger mit 100 Kernen einen 25-fachen Speedup zu erreichen, als mit 40 Kernen einen 10-fachen.

Re: SpeedUp

Verfasst: 22. Dez 2011 13:08
von mw1039
Genau. Allein schon deswegen, weil die Speicherbandbreite begrenzt ist.

Re: SpeedUp

Verfasst: 22. Dez 2011 18:52
von x539
mw1039 hat geschrieben:Genau. Allein schon deswegen, weil die Speicherbandbreite begrenzt ist.
Wenn ich das ganze mit 'time ./Praktikum4' messe, sollte sich die Speicherbandbreite doch in der USER-time und nicht in der SYS-time bemerkbar machen, oder?

Ich habe nämlich das Problem, das sich meine SYS-time bei 24 Threads (auf dem GRIS Rechner Nr.8 ), auf durchschnittlich 10min aufbläht (bei 4 threads 15s), während sie auf meinem Core i5 (2*2 kerne) ziemlich konstant bei knapp einer Sekunde bleibt.

Ich kann mir einfach nicht vorstellen wo er die Zeit im Kernel verbringen soll.

Re: SpeedUp

Verfasst: 22. Dez 2011 23:46
von kbraden
Wikipedia sagt zu dem Prozessor auf dem pcgris-teachnode er koenne 12 Threads gleichzeitig ausfuehren.
Meine Messungen bestaetigen das, ab 12 Threads wird meine Implementierung nicht mehr schneller.

In der Aufgabenstellung wird aber von 24 "virtuellen Kernen" gesprochen, was mich etwas verwirrt - hab ich irgendwo einen boesen Flaschenhals verbaut oder sind 12 Threads wirklich die Grenze hier?

Re: SpeedUp

Verfasst: 23. Dez 2011 10:20
von mw1039
Die Prozessoren haben Hyperthreading, d.h. einen doppelten Registersatz pro Kern. Wenn dann ein Prozess z.B. auf Speicheroperationen wartet, kann er, ohne den bisherigen Thread aufwaendig aus den Registern auslagern zu muessen, auf den zweiten Thread wechseln und die Wartezeit damit verbringen den zweiten Thread zu bedienen. Deswegen zwei virtuelle Kerne pro physikalischem Kern.
Ich bin mir nicht ganz sicher, ob du wirklich an das Limit der physikalisch vorhandenen Kerne rangelangst oder ob das irgendein anderes Limit ist, z.B. der Overhead durch das locken der Queue.
Wir ueberlegen deswegen aktuell, ob wir die Tutoren beim Testat die Threadzahl reduzieren lassen, z.B. auf 8 oder 12. Im Augenblick geb ich noch keine Garantie fuer diese Aussage, aber es ist wahrscheinlich, dass wir das machen und die geforderten Speedups sich dann auf diese Threadzahlen beziehen werden.
Es ist aber trotzdem interessant so einen Effekt mit abklingendem Speedup mal selbst zu sehen. Das naechste Praktikum wird ja OpenCL sein und da braucht man Probleme (oder muss sein vorhandenes Problem so umformulieren), dass man mehrere Zehntausend bis Millionen Threads ausgelastet bekommt.

Re: SpeedUp

Verfasst: 23. Dez 2011 14:15
von kbraden
mw1039 hat geschrieben:Die Prozessoren haben Hyperthreading, d.h. einen doppelten Registersatz pro Kern. Wenn dann ein Prozess z.B. auf Speicheroperationen wartet, kann er, ohne den bisherigen Thread aufwaendig aus den Registern auslagern zu muessen, auf den zweiten Thread wechseln und die Wartezeit damit verbringen den zweiten Thread zu bedienen. Deswegen zwei virtuelle Kerne pro physikalischem Kern.
Ich bin mir nicht ganz sicher, ob du wirklich an das Limit der physikalisch vorhandenen Kerne rangelangst oder ob das irgendein anderes Limit ist, z.B. der Overhead durch das locken der Queue.
Sorry, entweder wir reden aneinander vorbei oder ich steh auf dem Schlauch - daher nochmal konkrete Fragen: ;)

Der E5649 der verbaut ist hat wenn ich das richtig verstanden habe sechs Kerne - mit Hyperthreading (also zwei Registersaetze pro Kern) koennten dann 12 Threads gleichzeitig (oder zumindest mit geringem Overhead) laufen.
In /proc/cpuinfo stehen jetzt aber 24 Kerne - also: 1. sind zwei Prozessoren verbaut? 2. Stimmt was mit der Rechnung nicht? 3. Sollte das Praktikum hier halbwegs linear bis zu 24 Kernen skalieren oder nicht?

Danke und schoene Feiertage

Re: SpeedUp

Verfasst: 23. Dez 2011 20:58
von mw1039
Achso, ja, wir haben wirklich aneinander vorbeigeredet.
kbraden hat geschrieben:1. sind zwei Prozessoren verbaut?
Ja.
kbraden hat geschrieben:3. Sollte das Praktikum hier halbwegs linear bis zu 24 Kernen skalieren oder nicht?
Nein, nicht notwendigerweise. Die Queue zu locken etc. skaliert nicht beliebig. Deswegen werden wir wie gesagt wahrscheinlich nur auf 8 bis 12 Kernen testen.

Re: SpeedUp

Verfasst: 25. Dez 2011 16:02
von SupeRalF
Wird für die Zeitmessung im Testat eigentlich die Zeit mitberechnet, die das Programm braucht um die .obj Datei einzulesen? Weil das macht einige Sekunden aus und zieht daher den Speedup runter, so dass es bei meiner Implementierung bei 12 Threads relativ eng wird für die 2 Punkte.
Außerdem wäre es dann interessant, in welcher Auflösung testiert wird, denn je höher die ist, desto weniger wirkt sich das laden der .obj Datei aus.

Nebenbei bin ich auch dafür, mit maximal 8 oder 12 Threads zu testieren. Zumindest meine Implementierung profitiert von 24 Threads kein bisschen und hat eben sogar 1s länger gebraucht als mit 12 Threads.

Re: SpeedUp

Verfasst: 25. Dez 2011 23:30
von mw1039
SupeRalF hat geschrieben:Wird für die Zeitmessung im Testat eigentlich die Zeit mitberechnet, die das Programm braucht um die .obj Datei einzulesen?
Nein.
Es kann sein, dass wir zwecks einfacherer Mitstoppbarkeit der Zeit den Tutoren Zeiten vorgeben, die den kompletten Programmablauf, also auch das Laden der .obj, umfassen. Die werden dann aber quasi nur die Ausfuehrungszeit des zu parallelisierenden Teils geteilt durch die Anzahl der im Testat zu verwendenden Threads plus die sequentielle Ausfuehrungszeit (obj laden, bounding volume hierarchy basteln, Bild rausschreiben etc., das sind bei sponza.obj glaube ich 6s) umfassen. Das Laden etc. zu parallelisieren war ja in der Aufgabenstellung nicht gefordert.

メリー・クリスマス。

Re: SpeedUp

Verfasst: 3. Jan 2012 11:54
von keksberg
mw1039 hat geschrieben:Das Laden etc. zu parallelisieren war ja in der Aufgabenstellung nicht gefordert.
Ich nehme an, das gilt auch für den Contest und die Ladezeit wird da ebenfalls nicht mitberechnet?

Re: SpeedUp

Verfasst: 3. Jan 2012 14:17
von Thomas Huxhorn
Ja mehr Infos wäre toll.
Was ist mit dem Baum, wird diese Init Zeit auch gemessen?
Wo sind denn die Grenzen der Optimierungen die man durchführen darf? Oder dürfen wir alles ändern und alles benutzen solange wir es können?
Oder anders gesagt: solange noch in etwa das ursprüngliche Programm zu erkennen ist ;)