Wie Virtuelle von Physischen Kernen unterscheiden? (Hyperthreading)

[Jaho]

Hallo zusammen,

ich würde gerne wissen wie ich die Virtuellen Kerne von den physischen Kernen unterscheiden kann. Also z.b. mit dem Ressourcenmonitor, sind CPU0 und CPU1 praktisch die 2 Threads von Kern 1 und CPU2 und CPU3 die beiden Threads von Kern 2, oder wie ist das aufgeteilt?
Ich möchte einfach nachvollziehen ob die einzelnen physischen Kerne zuerst genutzt werden bevor z.b. 2 Threads auf einen Kern zugeteilt werden und ein Kern brach liegt.
Hoffe man kann meine Fragestellung einigermaßen verstehen.

MfG
Jaho

 

[Incredible Alk]

Das kannst du soweit ich weiß nicht so ohne weiteres nachvollziehen (ob da was sortiert wird weiß ich nicht). Windows7 ist in der Lage, diese Entscheidung intern vorzunehmen, was aber nicht immer 100%tig funktioniert, grade wenn die Last (wie etwa bei Spielen) stärker schwankt (deswegen laufen manche Spiele mit SMT langsamer als ohne).
Außerdem wird die Last auch öfter mal aus internen Gründen "umverteilt", was aber nicht schlimm ist da es dem physischen Kern egal ist ob der virtuelle Kern 1 oder 2 davon belastet wird - blöd wirds erst dann, wenn ein echter Kern 2 Aufgaben erledigen soll während ein anderer nichts zu tun hat - das kommt aber wie gesagt nur noch bei komplizierteren Lastgängen vor.
Die Umverteilungen und die Wahl der Auslastung kannst du dir ja im Task-Manager selbst ansehen wenn du deine 8 Thread / 4 Kern CPU mit Prime95 auslastest und dem Programm sagst es soll doch bitte 4 Threads benutzen

 

[Mastermaisi777]

Hallo zusammen,

ich würde gerne wissen wie ich die Virtuellen Kerne von den physischen Kernen unterscheiden kann. Also z.b. mit dem Ressourcenmonitor, sind CPU0 und CPU1 praktisch die 2 Threads von Kern 1 und CPU2 und CPU3 die beiden Threads von Kern 2, oder wie ist das aufgeteilt?
Ich möchte einfach nachvollziehen ob die einzelnen physischen Kerne zuerst genutzt werden bevor z.b. 2 Threads auf einen Kern zugeteilt werden und ein Kern brach liegt.
Hoffe man kann meine Fragestellung einigermaßen verstehen.

MfG
Jaho

Unter Windows sind die geraden(0,2,4,6) CPUs die echten und die ungeraden(1,3,5,7) die SMT Threads, beim Normalen Arbeiten einfach mal den Task Manager laufen lassen und du wirst sehen dass die echten Kerne viel mehr last bekommen als die SMT threads.

Wie du schon richtig erkannt hast ist dabei z. B. Kern 1 CPU 0 mit dem SMT Thread CPU 1.

Gesendet von meinem Galaxy Nexus mit Tapatalk

 

[OctoCore]

Zumindest unter Windows 7. Das sortiert wenigstens auch die "echten" Kerne immer gleich, die Vorgänger können sich da nicht entscheiden -die virtuellen stehen da aber auch in der zweiten Reihe

 

[Incredible Alk]

Zumindest unter Windows 7. Das sortiert wenigstens auch die "echten" Kerne immer gleich,

Aha funktioniert das mittlerweile tatsächlich so... ok in dem Falle kannst dus doch anscheinend im Task Manager herauslesen.

 

[Bioschnitzel]

....deswegen laufen manche Spiele mit SMT langsamer als ohne....

Afaik ist es eben seit Win7 nichtmehr der Fall, da es zuerst den echten Kernen die Arbeit zuweist. Bei XP und Vista war dies der Fall. Ich glaube das mal in der PCGH gelesen zu haben.

 

[Incredible Alk]

Afaik ist es eben seit Win7 nichtmehr der Fall, da es zuerst den echten Kernen die Arbeit zuweist. Bei XP und Vista war dies der Fall. Ich glaube das mal in der PCGH gelesen zu haben.

Auf jeden Fall ist das Problem mal deutlich geringer als noch zu XP Zeiten, ich glaube aber nicht dass es schon ganz beseitigt ist.
Win7 kann zwar mittlerweile gut mit SMT umgehen aber wenn ein Spiel da völlig verwirrt wird und die Threads und Lasten wild rumschaufelt kann das BS da auch nicht mehr alles reißen^^

 

[Cinnayum]

Da du jetzt weisst, welcher Kern echt und welcher nicht, was fängst du nun mit dieser Information an ?

 

[Bioschnitzel]

Auf jeden Fall ist das Problem mal deutlich geringer als noch zu XP Zeiten, ich glaube aber nicht dass es schon ganz beseitigt ist.
Win7 kann zwar mittlerweile gut mit SMT umgehen aber wenn ein Spiel da völlig verwirrt wird und die Threads und Lasten wild rumschaufelt kann das BS da auch nicht mehr alles reißen^^

Meinst du das der Computer verwirrt wird?

 

[Incredible Alk]

Meinst du das der Computer verwirrt wird?

Hehe, sozusagen
Es könnte zum Beispiel die Anweisungen im Spiel geben
1.: Mache so viele Threads wie CPU-Kerne da sind aber nicht mehr als 6.
2.: Belaste immer die CPU mit am wenigsten Auslastung mit der nächsten priorisierten Aufgabe

Wenn das Spiel jetzt auf einem 4 Kerner mit SMT läuft erkennt es 8 Kerne und baut 6 Threads zusammen. Win7 legt dann die Threads mit der größten Last auf die realen Kerne - wunderbar. Das hat zur Folge, dass die virtuellen Kerne natürlich möglichst gering ausgelastet werden sollen, da die Hauptarbeit ja die echten Kerne machen sollen.
Nun sieht das Spiel aber, dass da Kerne nichts tun - und gibt ihnen entsprechend die nächste Großaufgabe (das Spiel weiß ja nicht dass die Kerne die nichts tun virtuell sind und es auch so sein sollte). Die Folge ist, dass das Spiel genau die Kerne neu belastet die eigentlich nicht günstig sind dun das Betriebssystem wieder alles umbauen muss.

Das Spielchen geht dann immer hin und her - und die ganze ständige Umlagererei kostet Performance... obwohl weder das Spiel noch Windows was "falsch gemacht" hat.

 

[Bioschnitzel]

Naja, da denke ich aber das du selbst bei dem Szenario mit HT mehr FPS hast, als ohne HT

 

[Incredible Alk]

Naja, da denke ich aber das du selbst bei dem Szenario mit HT mehr FPS hast, als ohne HT

Das kommt darauf an wie ausgeprägt der Effekt ist. Win7 scheint mittlerweile so "intelligent" zu sein solche Rückkopplungen zu erkennen und sich dann rauszuhalten (auch wenn die Auslastung dann nicht ganz optimal wird). Früher gabs in dem Falle aber auch schon Performanceeinbrüche in bestimmten Spielen wo mit SMT/HT mal die hälfte oder mehr der fps weg waren weil das System nur noch damit beschäftigt war, die Daten in den einzel Caches der CPUs hin und her zu tauschen - und sonst fast nichts mehr ging.

Bei modernen Spielen/Systemen ist das Problem aber wie gesagt beinahe ausgestorben.

 

[Bioschnitzel]

Ja eben. ICh weiß das Vista noch nicht zwischen Physikalische und Logische Kerne unterscheiden konnte. Bei Win7 sollte das aber nichtmehr auftreten (bzw in Ausnahmefällen).

Generell ist HT in Kombi mit Win7 schon eine feine Sache

 

[Incredible Alk]

Naja ich habe in Spielen oder normalen Anwendungen noch nie einen Unterschied bemerkt ob ich SMT an oder aus habe, da ists völlig wurscht außer dass der geneigte Gamer im Task-Manager mit 8 Threads seinen virtuellen Schwanz verlängern kann

Bei Renderingaufgaben macht der Unterschied ob SMT an oder aus ist bei Vollast aller vorhandenen Threads grob 15% Zeitersparnis aus bei mir... da ists also durchaus ne nette Sache.

 

[Olstyle]

Richtig interessant wird SMT halt erst bei wenigen Kernen und im Zweifelsfall auch noch In-Order Architekturen. Ein Atom Prozzi gewinnt durch HT z.B. gerne mal 50% Leistung.
Wenn man eh schon genug Kerne hat um die Threads vernünftig unter zu bringen und die Auslastung der Pipelines dank "Out-of-order Execution" eh schon am Limit Kratz bringt HT natürlich nicht mehr so viel.

 

[Incredible Alk]

Richtig interessant wird SMT halt erst bei wenigen Kernen und im Zweifelsfall auch noch In-Order Architekturen. Ein Atom Prozzi gewinnt durch HT z.B. gerne mal 50% Leistung.
Wenn man eh schon genug Kerne hat um die Threads vernünftig unter zu bringen und die Auslastung der Pipelines dank "Out-of-order Execution" eh schon am Limit Kratz bringt HT natürlich nicht mehr so viel.

Stimmt, bei den kleinen Mobilen Zweikernern bringt SMT da vergleichsweise richtig viel.

 

[Andregee]

Allgemeint sagt man ja das kern 0, 2, 4, 6usw die realen Kerne sind, 1, 3,5 7 dir virtuellen. Aber angenommen ein Programm wird auf 0 und 3 gelagert,also auf einen echten und einen virtuellen Kern, muß man aber trotzdem sagen das das Programm auf 2 realen Kernen läuft.

 

[OctoCore]

Bei Renderingaufgaben macht der Unterschied ob SMT an oder aus ist bei Vollast aller vorhandenen Threads grob 15% Zeitersparnis aus bei mir... da ists also durchaus ne nette Sache.

Bei mir meist über 25% (29,7 hatte ich aber auch schon) - Wenn Avisynth mit in der Verarbeitungkette hängt, dann ist es auch nicht mehr soviel.

 

[Jaho]

Vielen Dank an alle für die sehr ausführliche erläuterung


MfG
Jaho

 

[Mastermaisi777]

Hehe, sozusagen
Es könnte zum Beispiel die Anweisungen im Spiel geben
1.: Mache so viele Threads wie CPU-Kerne da sind aber nicht mehr als 6.
2.: Belaste immer die CPU mit am wenigsten Auslastung mit der nächsten priorisierten Aufgabe

Wenn das Spiel jetzt auf einem 4 Kerner mit SMT läuft erkennt es 8 Kerne und baut 6 Threads zusammen. Win7 legt dann die Threads mit der größten Last auf die realen Kerne - wunderbar. Das hat zur Folge, dass die virtuellen Kerne natürlich möglichst gering ausgelastet werden sollen, da die Hauptarbeit ja die echten Kerne machen sollen.
Nun sieht das Spiel aber, dass da Kerne nichts tun - und gibt ihnen entsprechend die nächste Großaufgabe (das Spiel weiß ja nicht dass die Kerne die nichts tun virtuell sind und es auch so sein sollte). Die Folge ist, dass das Spiel genau die Kerne neu belastet die eigentlich nicht günstig sind dun das Betriebssystem wieder alles umbauen muss.

Das Spielchen geht dann immer hin und her - und die ganze ständige Umlagererei kostet Performance... obwohl weder das Spiel noch Windows was "falsch gemacht" hat.

Ehrlich gesagt glaube ich dass das Szenario in der Praxis(Spiele) nicht passiert, es ist eher so dass die Spiele so programmiert sind gewisse Tasks parallel zu auszuführen, in mehrere Threads, völlig unabhängig vom System auf dem es läuft.
Je nach Anzahl der Threads die das System zur Verfügung stellt kann der Scheduler die vom Spiel erzeugten Threads besser oder schlechter auf die Kerne auslagern bzw. es kann mehr parallel verarbeitet werden als hintereinander.

Hat man 20 Threads auf einem Single Core Rechner ohne SMT müssen sich die 20 Threads die Rechenzeit mit allen anderen teilen, der Scheduler versucht dabei allen Threads möglichst die gleiche Rechenzeit zu bieten(Idealisiert).
Hat man natürlich mehrere Kerne evtl. mit SMT kann man jedem Kern 2 Threads zuweisen die sich die Rechenzeit teilen.

Würde das Spiel wie oben beschrieben die Anzahl der erzeugten Threads auf das System anpassen müsste man während der Installation den Programmcode neu schreiben bzw. ändern, oder für alle möglichen Systeme eine passende Konfiguration bieten was de facto unmöglich ist.

In anderen Fällen kann man die Anzahl der Threads leichter anpassen , beim Rendering z.B. weil hier keine von einander abhängigen Probleme entstehen, man kann einfach den "Worker-Thead" mehrmals mit unterschiedlichen Start- und Endpunkten starten und hat eine quasi perfekte Skalierung. Aber auch hier würde der Scheduler die Verwaltung übernehmen und nicht die Software selbst.

Man denke an den Extremfall von mehreren Programmen die wie es ihnen so passt Kerne für sich beanspruchen, das würde nicht gut gehen

Das 2. Problem ist ebenfalls keines weil Spiele bzw. Programme sich normalerweise nicht in die Verwaltung der Threads einmischen weil sonst das von dir genannte Problem auftreten könnte, überlässt man dem OS die Verwaltung spart man sich nicht nur Programmcode man gewinnt auch Kompatibilität, das OS muss immerhin am Besten wissen worauf es eigentlich läuft, dafür gibt es Treiber und Informationen von der Hardware selbst die ein Programm nicht hat.

Ein Problem tritt nur dann auf wenn das OS zu wenig weiß, wie im Fall von SMT und einem OS das keine Ahnung von logischen Kernen hat, dem Spiel ist das herzlich egal.