Hyperthreading: Welcher Performance-Boost ist zu erwarten?

Naja, die 2-Kern-Teile mit HT sind ja eher Stromspar-Varianten oder Notebookprozessoren, so ist das halt heute

Wenn mir ein i7 30% Kompilierzeit einspart, dann ist das aber interessant für mich, auch wenn ich kein Powergamer bin und nur ab und an rendere oder Physiksimulationen laufen habe.

Im Moment stelle ich mir die Frage nach Hyperthreading Performance hauptsächlich weil ich nicht einschätzen kann ob im meinem Programm im Moment die Speicherbandbreite oder die tatsächlichen Berechnungen das Bottleneck sind. Ich dekodiere Bilder, und im Moment mache ich das stur bildweise, d.h. jeder von den 12 Threads bekommt ein ganzes Bild (~12 MB im Speicher) und rattert dann die komplette Dekodierungskette runter und produziert am Ende einen Output.

In den L3 Cache passt damit nichtmal ein einziges Bild. Mit der momentanten Bildbasierten Parallelisierung hole ich ca. eine 7-fache Performanceverbesserung heraus. Daher stellt sich mir die Frage, ob ich da mehr (8fach, 9fach?) rausholen könnte wenn ich das ganze nicht mehr bildweise parallelisiere sondern feingranularer arbeite um den Cache etwas besser auszunutzen (z.B. Farbtransformation einfach in 12 Threads aufteilen. Die arbeiten zwar Speichermäßig auch ein ganzes Stück auseinander, aber hierbei dürfte das Cache-Speicherringen bei weitem nicht so ausgiebig sein wie wenn 12 Threads mit ~140MB an Daten um sich schlagen). Wäre das nicht der Fall, dann würde ich die nächtsen paar Wochen lieber auf code-technischer Ebene "mikro-"optimieren anstatt extra einen passenden Scheduler zu implementieren.

Der 7-fache Faktor ergibt sich einfach daraus, dass ein Bild im Moment in einem einzelnen Thread etwa 340ms zum dekodieren braucht und 12 Bilder mit 12 Threads resultieren etwa in 50ms pro Bild ->~7.

volkard

Decimad schrieb:

Naja, die 2-Kern-Teile mit HT sind ja eher Stromspar-Varianten oder Notebookprozessoren, so ist das halt heute

Wenn mir ein i7 30% Kompilierzeit einspart, dann ist das aber interessant für mich, auch wenn ich kein Powergamer bin und nur ab und an rendere oder Physiksimulationen laufen habe.

Bevor Du Dich in Unkosten stürz, messe ich nochmal genau.
Linux-Kernel mit und ohne HT. edit: Nee, was anderes großes mit C++ drin. Mal schauen. boost.
Bis gleich.

Vielen Dank!

knivil

Wenn mir ein i7 30% Kompilierzeit einspart, dann ist das aber interessant für mich, auch wenn ich kein Powergamer bin und nur ab und an rendere oder Physiksimulationen laufen habe.

Und wenn du dir stattdessen eine SSD kaufst oder genug RAM fuer eine grosse Ramdisk?

Es gibt verschiedentliche Threads im Internet zu finden, die bei aktuellem VC++ keinen Unterschied zwischen Ramdisk und echter Disk feststellen können, weil der Compiler/Buildprozess klug cached, so die Theorie.
Davon ab ist eine SSD aber sowieso Pflicht für meinen neuen Rechner, nur wird das eben keine Auswirkungen auf den Kompilier-Prozess haben, wenn die IDE erstmal warmgelaufen ist.

volkard

boost.

Ohne HT
real 2m5.835s
user 6m2.077s
sys 0m35.369s

Mit HT
real 1m48.567s
user 9m33.866s
sys 0m45.508s

Naja, immerhin rund 15%.
edit: nochmal gemessen, diesmal auf ramdisk.

@Volkard: Lese ich korrekt heraus, dass es ohne HT 11% länger dauert und "50% weniger Strom" braucht?

Decimad schrieb:

@Volkard: Lese ich korrekt heraus, dass es ohne HT 11% länger dauert und "50% weniger Strom" braucht?

Wie kommst du auf 50% weniger Strom? Das wurde doch garnicht gemessen.

Edit: Ach du meinst, dass für die "HT-Threads" die Leistungsaufnahme verdoppelt? Nein, das ist mitnichten so. Eigentlich sollte die Effizienz (gerechnetes pro Watt) tendenziell mit HT etwas höher sein.

Naja, ich meine, dass die aktive Ausführungszeit (User+Sys) ja um 50% gestiegen ist mit HT, also der Prozessor weniger wartenden Idle hatte, oder nicht?

Edit: Real zu User korrigiert

volkard

Decimad schrieb:

@Volkard: Lese ich korrekt heraus, dass es ohne HT 11% länger dauert und "50% weniger Strom" braucht?

Weit gefehlt. Verbrauch des gesamten Rechners ohne Monitor:

Ohne HT:
Idle 37.6 Watt
Vollast 96.3 Watt

Mit HT:
Idle 37.6 Watt
Vollast 104.1 Watt

volkard

Decimad schrieb:

Naja, ich meine, dass die aktive Ausführungszeit (User+Sys) ja um 50% gestiegen ist mit HT, also der Prozessor weniger wartenden Idle hatte, oder nicht?

Daraus lese ich eigentlich nur, daß mit HT alles pro Thread viel viel langsamer geht, aber die doppelte Threadzahl das überkompensiert.

Und vielleicht, daß man dafür wohl keine parallelen Algos schreiben sollte, die bei Verdoppelung der Threadzahl die Zeit nicht fast halbieren.

Ist das ein i7 3770, den Du da hast? Hrmm, knapp 80eu über dem entsprechenden i5 3570.

Lohnt in den seltensten Fällen der 3770.

volkard

Decimad schrieb:

Ist das ein i7 3770, den Du da hast? Hrmm, knapp 80eu über dem entsprechenden i5 3570.

Nein. Ein alter Intel Core i7-2600K, 4x 3.40GHz
http://geizhals.at/de/580311

rapso

hyperthreader schrieb:

Im Moment stelle ich mir die Frage nach Hyperthreading Performance hauptsächlich weil ich nicht einschätzen kann ob im meinem Programm im Moment die Speicherbandbreite oder die tatsächlichen Berechnungen das Bottleneck sind. ...(~12 MB im Speicher) ... 50ms pro Bild

sind 240MB/s und somit vermutlich nicht das bottleneck. ein 7x speedup sind 13% (340/6ms vs 50ms) mehr als du ohne HT haben solltest, somit duerfte es schon recht optimal laufen.
Hyperthreading zieht zudem seinen vorteil daraus, wenn du speicher limitiert bist, das ein thread arbeiten kann, waehrend ein anderer auf speicher wartet.

rapso, könnte es nicht sein, dass die Threads sich gegenseitig so sehr den Cache streitig machen, dass öfter als nötig der Cache gleich runderneuert werden muss? Also dass die Bilder hinterher in der Praxis mehrfach durch die Speicherleitungen fließen?

rapso

Decimad schrieb:

rapso, könnte es nicht sein, dass die Threads sich gegenseitig so sehr den Cache streitig machen, dass öfter als nötig der Cache gleich runderneuert werden muss? Also dass die Bilder hinterher in der Praxis mehrfach durch die Speicherleitungen fließen?

sowas kann natuerlich passieren, gerade aeltere CPUs waren darauf sehr anfaellig und die allokatoren bis heute verhalten sich in dieser hinsicht nicht zu smart, aber mittlerweile sind die CPUs besser ausgelegt z.b. ist der L3 cache von ivy bridge 32 fach assoziativ, eigentlich ein irrsin bei single core, aber gut um address collisions zu vermindern.
ich denke die resultierende performance von 7x zeigt auch, dass es wohl gut geht.

Michael E.

Decimad schrieb:

Wenn mir ein i7 30% Kompilierzeit einspart

30% schneller ergibt eine um 23% geringere Kompilierzeit.