Hyperthreading: Welcher Performance-Boost ist zu erwarten?

volkard

nichtkenner der hyperthre schrieb:

Bei mehreren echten Kernen bekommt man es ja mit etwas Arbeit ganz gut hin bei n Kernen auch etwa eine n-fache Performanceverbesserung zu erzielen. Wie sieht's da mit Hyperthreading aus? Leistet das tatsächlich genug dass man bei beispielsweise 6 Kernen und damit 12 logischen Threads tatsächlich einen Faktor von 10-12 rausbekommt?

Beim Compilieren auf dem I7 mit reichlich RAM bringt jeder weitere Kern sich mit 100% ein, also 4Kerne -> 400%. Und jeder Hyperthread mit 30%. Also 4HT-Kerne -> 520% statt 800%. So meine dürftigen Messungen.
Ich vermute, daß bei rechenintensiven Sachen, bei 3d-Spielen, die Sache eher weit unter 30% liegen wird.

Och nöööö Volkard ... Ich hatte mit nem i5 spekuliert, weil ich meinte, dass der Compiler nur die Integereinheiten voll auslastet und mir daher Hyperthreading nix bringen würde. So ein i7 kostet dann ja doch ein paar Tacken mehr -.-

dot

Decimad schrieb:

Ich hatte mit nem i5 spekuliert, weil ich meinte, dass der Compiler nur die Integereinheiten voll auslastet und mir daher Hyperthreading nix bringen würde.

Kanns sein, dass du da was verwechselst!? Alle Intel Core iIrgendwas haben Hyper-Threading...

Wut? Ich denke doch, dass nur der i7 Hyperthreading angeschaltet hat?

Edit: Und mein Notebook-i5 hat nur 2 Kerne und wird mit Hyperthreading auf 4 gebracht. Aber Desktop i5s haben kein Hyperthreading.

nman

dot schrieb:

Kanns sein, dass du da was verwechselst!? Alle Intel Core iIrgendwas haben Hyper-Threading...

Nein, zumindest bei den Sandybridge-CPUs war das definitiv noch nicht der Fall. Damals hatten nur die i7-CPUs Hyperthreading.

rapso

dot schrieb:

Decimad schrieb:

Ich hatte mit nem i5 spekuliert, weil ich meinte, dass der Compiler nur die Integereinheiten voll auslastet und mir daher Hyperthreading nix bringen würde.

Kanns sein, dass du da was verwechselst!? Alle Intel Core iIrgendwas haben Hyper-Threading...

nein, gibt viele i5 die kein HT haben z.b.
http://ark.intel.com/products/65520/Intel-Core-i5-3570K-Processor-6M-Cache-up-to-3_80-GHz

gibt aber auch i5 die 2core und 4threads haben beim desktop, glaube es gibt aber nur quadcores mit HT beim i7.

@topic
in meinen programmen bringt HT bestenfalls 30%, manchmal aber auch -10% wenn man alle 12 threads voll auslastet.

dot

Selbst viele i3 haben Hyper-Threading, aber stimmt, es gibt offenbar tatsächlich sogar aktuelle iIrgendwas ohne Hyper-Threading, was mir ehrlich gesagt nicht bewusst war (bei meiner stichprobenartigen Suche sind mir die wohl irgendwie alle entgangen). Worauf ich eigentlich hinauswollte war: Aus i5 folgt nicht automatisch, dass er kein Hyper-Threading hat...

Bitte nenne mir die 4-Kern i5 mit Hyperthreading, einen davon werde ich mir kaufen!

rapso

sowas gibt es nicht, benutz die suche von intel um durch deren namens/cpu wirrwar durchzukommen:

http://ark.intel.com/search/advanced/?s=t&FamilyText=3rd Generation Intel Core i5 Processors&CoreCountMin=4&CoreCountMax=4&HyperThreading=true

was mir jetzt erst so richtig aufgeht wie unglaublich viele variationen die haben. frueher gab es nen p75 p90 und dann kam p100 p120 dazu, heute

_matze

dot schrieb:

Aus i5 folgt nicht automatisch, dass er kein Hyper-Threading hat...

Na aber so gut wie.

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