Hyperthreading Performance

[schnurri]

Hallo Leute, ich habe ein kniffliges Performanceproblem, zu dem ich bisher keine brauchbaren Infos gefunden habe.

Bei mir läuft ein OpenGL Programm unter WinXP32 auf einer NVidia Karte. Das Programm hat nur einen User Mode Thread, im Task Manager werden aber 2 Threads angezeigt (jeweils 70-100 % Auslastung pro Core). Offenbar hat der NVidia Treiber einen eigenen Kernel Mode Thread. So weit, so gut.

Auf einem Core 2 Quad gibt es bekanntlich 2 DualCores. Wenn ich das Programm auf diesem QuadCore laufen lasse, gibt es erhebliche Performance Unterschiede, je nachdem, ob es auf Core 0+1 läuft oder auf Core 0+2. Das ist auch verständlich, da Core 0+1 auf demselben DualCore sind und intern kommunizieren, während Core 0+2 auf zwei verschiedenen DualCores sind und extern kommunizieren müssen.

Bei den neuen Core i5/i7 gibt es nun welche mit und welche ohne Hyperthreading. Dieses Hyperthreading ist schön, wenn man 8 Threads am Laufen hat. Wenn aber nur 2 Threads laufen, besteht die Gefahr, daß WinXP diese beiden Threads auf einem einzigen Core laufen läßt. Dadurch wird das Programm merklich langsamer.

Hat schon jemand Erfahrungen oder einen Link zu diesem Thema "Hyperthreading auf MultiCore"?

 

[X909]

Da hilft manuelle CPU-Zuweisung (Taskmanager oder über ein Programm) oder Windows 7.

 

[jni]

Windows 7 soll wohl was von Hyperthreading wissen und versucht die Threads sinnvoll zu verteilen. Bei XP gibts so was nicht. Da hilft wohl wirklich nur ne manuelle Zuweisung. Da man da ne Maske angeben kann sollte das recht sinnvoll funktionieren.

 

[schnurri]

Zur Zeit mache ich die CPU Zuweisung mit SetProcessAffinityMask. Das Problem ist nur, daß WinXP bei jedem Reboot die CPUs anders durchnumeriert, mal funktioniert Maske 1100, mal 1010 und mal 1001. Es gibt in der Win32 API auch keine Möglichkeit herauszufinden, welcher CPU Index welchem physischen Core zugeordnet ist. Schöne Hightech shice

Kann man das irgendwo nachlesen, daß der Win7 Task Scheduler etwas von Hyperthreading versteht? Ansonsten kommt wohl nur ein Core i5 infrage oder beim Core i7 im BIOS Hyperthreading ausschalten.

 

[Kephis]

Zur Zeit mache ich die CPU Zuweisung mit SetProcessAffinityMask. Das Problem ist nur, daß WinXP bei jedem Reboot die CPUs anders durchnumeriert, mal funktioniert Maske 1100, mal 1010 und mal 1001. Es gibt in der Win32 API auch keine Möglichkeit herauszufinden, welcher CPU Index welchem physischen Core zugeordnet ist. Schöne Hightech shice

Kann man das irgendwo nachlesen, daß der Win7 Task Scheduler etwas von Hyperthreading versteht? Ansonsten kommt wohl nur ein Core i5 infrage oder beim Core i7 im BIOS Hyperthreading ausschalten.

Guck mal hier nach:
http://www.tomshardware.com/news/windows-hyperthreading-intel-nehalem-atom,7831.html
http://www.informationweek.com/news/windows/operatingsystems/showArticle.jhtml?articleID=217500139
http://www.tomshardware.com/news/Intel-CPU-Windows-7-Optimizations,8337.html

 

[schnurri]

Danke für die Links, aber das einzig konkrete, was man da lesen kann, ist das SMT Parking, z. B. auch hier.

Bei neueren CPUs hängt die Performance immer mehr von Speicherzugriffen ab, die Bedeutung der Rechenoperationen an sich wird relativ geringer. Wenn Threads (wie bei WinNT bis Vista) ständig von einem Core zum anderen wechseln, gehen auch ständig die L1 und L2 Caches verloren. Durch das SMT Parking bleiben die Threads länger auf einem Core, wodurch natürlich die Caches besser ausgelastet werden und Performance steigt.

Das hat aber nichts mit meinem ursprünglichen Problem zu tun. Bei diesem Screenshot

ist nicht erkennbar, ob Core 0+1 und Core 2+3 per Hyperthreading auf denselben physischen Cores laufen. Wenn dem so ist, würde das Programm auf Core 0+2+4+6 schneller laufen.

Edit:

Habe gerade endlich mal etwas Bauchbares gefunden

The basic notion behind SMT parking is that the Windows scheduler will attempt to schedule threads so that all physical cores are occupied before any core gets two threads scheduled on its two front-ends (or logical cores). Since Hyper-Threading involves some cache partitioning and other forms of resource sharing, this is a potentially important feature. We've seen scheduler quirks cause poor and oddly unpredictable performance on Core i7 processors in the past. Based on our limited experience testing with Windows 7 and a cadre of SMT-enabled processors for this review, our initial impressions of SMT parking are positive. We've seen performance results for executables that rely on the Windows scheduler for thread allocation that match the performance of executables with explicit, SMT-aware thread affinity built in. Our initial sense is that SMT parking blunts some potential disadvantages of Hyper-Threading, making it more of an unqualified win, even on the desktop.

Mit Win7 wird also alles besser, bleibt noch die Frage, wie das mit aktuellen Linux kernels und Core i7 aussieht?

 

[Kephis]

Danke für die Links, aber das einzig konkrete, was man da lesen kann, ist das SMT Parking, z. B. auch hier.

Bei neueren CPUs hängt die Performance immer mehr von Speicherzugriffen ab, die Bedeutung der Rechenoperationen an sich wird relativ geringer. Wenn Threads (wie bei WinNT bis Vista) ständig von einem Core zum anderen wechseln, gehen auch ständig die L1 und L2 Caches verloren. Durch das SMT Parking bleiben die Threads länger auf einem Core, wodurch natürlich die Caches besser ausgelastet werden und Performance steigt.

Das hat aber nichts mit meinem ursprünglichen Problem zu tun. Bei diesem Screenshot

ist nicht erkennbar, ob Core 0+1 und Core 2+3 per Hyperthreading auf denselben physischen Cores laufen. Wenn dem so ist, würde das Programm auf Core 0+2+4+6 schneller laufen.

Deine Fragestellung zielt dann aber nur auf die alten Intel Quads ab, also die Core2 CPUs. Die Lynfield/bloomfield und konsorten sind ja alle "native" Quadcores. Oder verstehe ich deine Frage irgendwie falsch?

 

[schnurri]

Das Problem betrifft sowohl die Core 2 Quads als auch Core i7, nicht aber Core i5 oder Phenom.

Es geht hier um Worker Threads, die richtig Last produzieren. Idle Threads, die 99% der Zeit schlafen, kann ich auch auf einem SingleCore ohne Hyperthreading laufen lassen.

Der Core 2 Quad hat 4 logische Cores, die physisch auf 2 DualCores liegen. Wenn ich ein Programm mit 2 Workerthreads habe und jeweils Core 0+1 und 2+3 zusammengehören, habe ich einen erheblichen Performanceunterschied. Auf Core 0+1 läuft das Programm schnell, auf Core 0+2 läuft es langsam.

Beim Core i7 habe ich 8 logische Cores und betrachte ein Programm mit 4 Workerthreads. Wenn jeweils Core 0+1, 2+3, 4+5 und 6+7 per Hyperthreading zu einem physischen Core gehören, läuft mein Programm auf 0+1+2+3 langsam und auf 0+2+4+6 schnell.

Wie in meinem Edit oben zu lesen, scheint der Win7 Task Scheduler die Variante zu beherrschen, in der alle Cores erst ausgelastet werden, bevor mit Hyperthreading ein Core doppelt belastet wird. Bei den Win7 Vorgängern ist das reine Glückssache. Mich würde nun noch interessieren, ob in dieser Hinsicht die aktuellen Linux Kernel etwas haben.

Edit:

Ich habe jetzt endlich mal eine Original Quelle gefunden (nicht von Journalisten irgendwo abgeschrieben). Da ist auch SMT Parking genauer beschrieben. Es ist nicht (wie ich oben dachte) das Parken von Threads auf einem Core, sondern das Parken von HT Cores solange noch native Cores verfügbar sind.

Windows 7 & Westmere: Better Together
• Idle Core: When the OS scheduler has a new thread to assign to a core, it will now check to see if an idle core is available, and if so, assign the new thread to that idle core.
• Quantum End: a time-slice for executing tasks. At the end of that time-slice the OS scheduler will look at threads in flight, and see if an idle core has become available. If so, a thread being executed on an HT core will be migrated over to the idle physical core to accelerate its execution.
• SMT Parking & Core Parking:
– SMT Parking: keeps HT cores parked until physical cores are busy to the point that the HT cores are needed.
– Core Parking: OS scheduler will “park” entire cores that aren’t being used, and those cores are then put into a deep-sleep state called C6. Used only in servers.

 

[PitGST]

@Kephis
Mach doch bitte das Bild aus dein Quote heraus, das Bild ist doch direkt über dein Beitrag und macht den Thread unnötig lang.

 

[jni]

@schnurri:

Die Numerierung der CPU-Kerne ist bei einem Core 2 Quad 100% stabil - zumindest unter Vista und Win 7 (unter XP geht's bestimmt auch - kann ich nur gerade nicht testen). Also immer erst beide Cores auf dem selben Die und dann die anderen beiden. Ich hab ein Programm mit mehreren Threads was auch stark Cachesensitiv ist. Die Zuweisung mittels der SetThreadAffinityMask-Funktion ergibt immer reproduzierbare Performance-werte.

Ich denke auch, daß beim Core i7 mit HT eine stabile Prozessorzuweisung möglich ist, sonst hätte ja jemand einen ziemlichen Unsinn produziert.

 

[schnurri]

Auf meinem Testsystem mit Core2 Quad und WinXP32/WinXP64 werden die Cores nachweislich bei jedem Reboot anders durchnumeriert. Kann auch sein, daß das gar nicht an Windows liegt sondern an Chipsatz/BIOS. Jedenfalls ist es ärgerlich, und man hat über die Win32 API keine Möglichkeit, nähere Infos über die physischen Cores zu bekommen. Solche Programme wie CPU-Z greifen bei einigen Infos wahrscheinlich direkt auf die CPU zu.

Aus der Stellungnahme von Intel und Microsoft zum Win7 Task Scheduler ist erkennbar, daß Win7 vernünftig mit Multicore Hyperthreading umgehen kann. Daraus folgt aber auch, daß es bei den Win7 Vorgängern reine Glückssache ist. Bei einem Programm mit 2 Workerthreads kann es sein, daß sie mit Hyperthreading auf demselben Core laufen und sich gegenseitig behindern.

 

[wosch666]

Ich habe mal diesen alten Thread wieder ausgegraben, weil er durch Bulldozer wieder interessant wird.

Win7 "kennt" also Hyperthreading, aber was ist dann mit dem Core3Quad-Problem und wie verhällt sich Win7 dann beim Bulldozer?
Auch beim Bulldozer sind 2 zusammengehörende Kerne wohl langsamer, als wenn ich die Threads auf unterschiedliche Module aufteile.

Beim Core2Quad ist es sogar genau andersrum. Wenn ich die Threads auf einen der beiden Prozessoren verteile, dann ist es schneller als wenn sie auf den unterschiedlichen DIEs laufen.

Wie geht Win7 mit Core2Quads und dem Bulldozer um?
Gibt es unter Linux entsprechende Maßnahmen für Hyperthreadingoptimierungen?

Vermutlich wird AMD wohl wieder einen Prozessortreiber herausgeben müssen, wenn die Betriebssysteme nicht zwischen Bulldozermodulen und kernen unterscheiden können.

 

[Unisolblade]

Genau aus diesem Grund hab ich Hyperthreading aus. Beim zocken bringts eh nix und hab so auch mehr als genug Leistung

 

[X909]

AMD wird die zusammengehörigen logischen CPUs wohl als solche Kennzeichnen. Dann kann der Scheduler vom Windows 7 genauso sinnvoll verteilen wie im Falle von Hyperthreading. Es handelt sich ja in beiden Fällen um SMT, nur eben mit unterschiedlicher Herangehensweise.

HT abzuschalten bringt bei Win7 eigentlich nur Nachteile.

 

[Opteron]

Ich habe mal diesen alten Thread wieder ausgegraben, weil er durch Bulldozer wieder interessant wird.

*lach* Hast Dus im anderen Thread gesehen ? Da hatten wir das Thema auch gerade.

Win7 "kennt" also Hyperthreading, aber was ist dann mit dem Core3Quad-Problem und wie verhällt sich Win7 dann beim Bulldozer?
Auch beim Bulldozer sind 2 zusammengehörende Kerne wohl langsamer, als wenn ich die Threads auf unterschiedliche Module aufteile.

Beim Core2Quad ist es sogar genau andersrum. Wenn ich die Threads auf einen der beiden Prozessoren verteile, dann ist es schneller als wenn sie auf den unterschiedlichen DIEs laufen.

Ich nehme an, dass AMD die Kerne in den Modulen auch als SMT Kerne flaggt, auch wenns nicht wirklich SMT ist. Aber es sollte das beste Resultat liefern.
Bei dem bisherigen Szenario mit dem C2Q muss man aber unterscheiden.
Es kann sein, dass es auch Workerthreads gibt, die auf Core0+2 schneller laufen würden. Nämlich dann, wenn die 2 Threads unabhängig wären. Zum Beispiel bei Renderthreads, der eine Thread berechnet den oberen Teil, der andere den unteren, da brauchts nicht viel Kommunikation.

Wenn man aber viel inter-core traffic hat, da die Ergebnisse der beiden Threads immer wieder ausgetaucht werden müssen, dann läufts natürlich besser, wenn beide Threads auf einem DIE blieben. Davon gehe ich im geschilderten Fall von OpenGL Programm und Grafiktreiber aus.
Bei Bulldozer wärs jetzt vermutlich fast egal, so groß ist die Latenz zw. 2 Modulen dann auch nicht, dass es einen dicken Performanceeinbruch geben sollte.

Wie geht Win7 mit Core2Quads und dem Bulldozer um?
Gibt es unter Linux entsprechende Maßnahmen für Hyperthreadingoptimierungen?

Linux hatte meines Wissens nie ein Problem damit, aber ich lass mich gerne eines besseren belehren

Vermutlich wird AMD wohl wieder einen Prozessortreiber herausgeben müssen, wenn die Betriebssysteme nicht zwischen Bulldozermodulen und kernen unterscheiden können.

Nö, es reicht, wenn sie die INT Cluster als logische CPU "flaggen", hat auch den Vorteil, dass alles ohne Probleme läuft.

AMD wird die zusammengehörigen logischen CPUs wohl als solche Kennzeichnen. Dann kann der Scheduler vom Windows 7 genauso sinnvoll verteilen wie im Falle von Hyperthreading. Es handelt sich ja in beiden Fällen um SMT, nur eben mit unterschiedlicher Herangehensweise.

Hm nö, das "S" von SMT steht ja für simultan, das "C" in CMT für cluster. Das ist nicht das eben nicht gleiche, Bei Intel laufen 2 Threads simultan/gleichzeitig durch die gleichen Pipelines und den gleichen L1 Cache, bei CMT passiert das nicht, da sind 2 Threads streng getrennt. Jeder Thread hat da seinen Cluster, gibt sogar nen extra L1D Cache.

Ausnahme im Bulldozer Fall ist nur die FPU, da es nur INT Cluster gibt. Die FPU kann man als SMT bezeichnen. Zwar besteht die auch aus 2 Hälften, aber es gibt keine strikte Trennung, ergo kann es hier dann vorkommen, dass 2 Threads parallel/simultan abgearbeitet werden.

Das Ergebniss mag bei SMT/CMT zwar gleich erscheinen (2 Threads auf einem Kern), aber die Art und Weise ist schon unterschiedlich.

 

[che new]

Beim Core2Quad ist es sogar genau andersrum. Wenn ich die Threads auf einen der beiden Prozessoren verteile, dann ist es schneller als wenn sie auf den unterschiedlichen DIEs laufen.

Die beiden DIEs im Core2Quad mussten aber über die Northbridge im Chipsatz kommunizieren, also per langsamen, limitierenden FSB.

Die Module im Bulldozer dagegen kommunizieren afaik über den L3 Cache der direkt in der CPU sitzt.