Threads im Taskmanager abschalten

[sTOrM41]

Moin,

ich würde gerne mal testen inwiefern bestimmte spiele von verschiedener anzahl an threads profitieren (oder eben auch nicht).

am einfachsten lässt sich das wohl realisieren indem ich im taskmanager die threads zuweise.

meine frage dabei nun:
welche threads sind virtuelle threads (hyperthreading) und welche sind echte cpu kerne? (i7 8700)

 

[Sir Diablo]

Gerade isn echter Kern ungerade SMT

 

[sTOrM41]

super, danke

 

[Kullberg]

Die Geraden und die Ungeraden sind gleichwertig. Es ist also egal, ob man 0,2,4,6... setzt oder 1,3,5,7...

 

[Sonnenbluemchen]

Die Geraden und die Ungeraden sind gleichwertig. Es ist also egal, ob man 0,2,4,6... setzt oder 1,3,5,7...

Wenn SMT aus ist/die CPU kein SMT hat ist es egal, ansonsten gilt was Sir D geschrieben hat.

 

[Kullberg]

@Sonnenbluemchen
Hast Du es ausprobiert? Bestimmt nicht. Ich hab selbst ein Tool in C++ programmiert, was Affinities (in meinem Fall von Schachprogrammen) setzt. Es ist völlig egal, ob man die geraden oder ungeraden Cores verwendet. Und dass sowas nur Sinn macht, wenn HT / SMT an ist, ist selbstverständlich - hoffentlich.

@Threadstarter
Ein Problem kann es allerdings geben. Schau mal im Taskmanager nach, wieviele Threads das Spiel hat. Wenn es alle logischen Cores verwendet, kann man durch so eine Aktion die Performance nur reduzieren. Denn das Spiel wird die Anzahl der Threads nachträglich nicht anpassen - auch wenn es real weniger Cores zur Verfügung hat.

 

[fdsonne]

Gerade isn echter Kern ungerade SMT

Es gibt keine echten oder unechten "Kerne"
Es gibt da im Taskmanager im Grunde gar keine Kerne. Es gibt nur Threads.
Und pro physischen Core meldet eine CPU, die SMT kann entsprechend viele Threads. Wie viele das sind, hängt vom Prozessor ab (es gibt auch 4-way SMT bspw. - also 4x Threads pro Core)

Weiterhin sind die gemeldeten Threads gleichwertig, Kullberg ist hier zuzustimmen.
Vllt ist es einfacher zu sagen, dass immer ein gerader und der darauf folgende ungerade Thread zu einem physischen Core gehören. Begonnen wird mit der Zählung bei 0.
Ob du da auf Thread 2 oder Thread 3 Last anlegst, ist völlig egal. Die Arbeit ist schlicht gleich schnell abgearbeitet.

Eine Sonderstellung hat hier Thread 0, der gewisse Sachen pauschal aufgedrückt bekommt und die man dort ggf. auch so gar nicht wegbekommt. Heist also in einem Test könnte Thread 0 also langsamer als ein anderer Threads sein - weil Hintergrundlast dort drin rum fingert.


Des weiteren sollte man, je nach Prozessormodell darauf achte, wie die interne Verschaltung der CPUs ist. Gutes Beispiel ist hier AMD Ryzen - 2x CCXen = 2x L3 Cache Blöcke. Ein Task, der über die CCX-Blöcke hinweg Leistung abruft, muss ggf. Daten über die IF übertragen, was höhere Latenz bedeutet und im Zweifel Leistung kostet.
Bei TR/Epyc ist das sogar noch schlimmer, da kommen logisch mehr NUMA Nodes dazu.


@sTOrM41
der Test wird so nicht aussagekräftig sein.
Damit das "Sinn" ergibt solltest du lieber im Bios/UEFI die Cores limitieren.
Warum? Kullberg hat es schon angerissen - Software bildet gern die Anzahl der Threads, die genutzt werden anhand der physisch gemeldeten Threads vom Prozessor. Einfach nur die Affinität zu kastrieren bedeutet im Zweifel aber, dass zu viele Threads anstehen und das Ergebnis verfälschen. (auch wenn diese vllt sehr schnell abgearbeitet werden)
Deswegen sollte man das hart im Bios ausschalten. Technisch müsste aber auch das runterdrehen via "msconfig" gehen... Ein Boot ist aber zwangsweise notwendig um den Spaß zu ändern. Egal ob Bios/msconfig

 

[sTOrM41]

übers bios ist es halt in sofern doof das ich dann immer rebooten muss..

schwierig so ein multiplayer spiel wie hunt showdown zu testen :/

aber geht dann wohl nicht anders..

 

[fdsonne]

Dafür ist es halt definitiv gesichert, dass du realistisch die Coreanzahl simulieren kannst...
Der Rest ist halt nur rumgestocher - da vor allem das OS auch etwaige Last abseits des gebenchten Tasks dann auf die von dir nicht gesetzten Threads legen wird.

 

[Holt]

Nur mal so am Rande: Mit cmd.exe /c start "MeinProgramm" /affinity 0x55 "C:\Pfad\MeinProgramm.exe" kann man erreichen das ein Programm nur den gerade Kernen einer CPU mit 8 Threads startet, mit 0xAA als Mask dann eben auf den ungerade. Dazu muss man sich kein Programm schreiben, ein passender Shortcut der den entsprechenden Aufruf enthält tut es auch.

 

[Kullberg]

@Holt
Schachprogramme bestehen aus der GUI und der Engine. Die Engine verbraucht fast 100% Rechenleistung. Einige Engines laufen besser, wenn sie nur auf physikalischen Cores laufen. Da ist es optimal, wenn nur Affinities für die Engine gesetzt werden und die GUI auf anderen logischen Kernen läuft. Die GUI startet die Engine - da kann man keine zusätzlichen Kommandos für den Start definieren. Also brauche ich dafür ein Programm.

 

[satuan]

Nur mal so am Rande: Mit cmd.exe /c start "MeinProgramm" /affinity 0x55 "C:\Pfad\MeinProgramm.exe" kann man erreichen das ein Programm nur den gerade Kernen einer CPU mit 8 Threads startet, mit 0xAA als Mask dann eben auf den ungerade. Dazu muss man sich kein Programm schreiben, ein passender Shortcut der den entsprechenden Aufruf enthält tut es auch.

Windows kann ab bestimmten Versionen physikalische und logische Kerne auseinanderhalten und über UMS auch Prioritäten zuteilen. Ob sich das für aussagekräftige Testergebnisse eignet müsste der TS selbst herausgekommen, da die Anwendung eine Sheduler Komponente anfordern muss. Mit dem einfachen zuteilen von physikalischen Kernen ist es nicht getan. Das Problem kann dann sein das z.B. eine dll Loadersperre zu einem Deadlock führt. MS rät davon ab, da ein Code der eine Threadpriorität oder Affinität festlegt, vom Scheduler im Sinne der Workloadstabilität überschrieben werden kann, wenn ein kernelasynchroner Prozeduraufruf möglicherweise den Kontext verriegelt.

Das würde ja nicht helfen, sondern die Ergebnisse verfälschen oder alles zum Absturz bringen. Also ist dann für mich auch nicht klar ob Core 0-1-2-3 tatsächlich nur dem Spiel zugeordnet wird. Manuelle Systemaufrufe mit Prioritätzuteilung über den UMS sollen daher vermieden werden. Da haben sie hier schon Recht.

 

[angelsdecay]

Dafür gibt es Programme die das berücksichtigen ob smt an ist oder nicht und kann die Zuteilung der software festlegen
manuell
Prozessorlasso
processexplorer (microsoft kein installer muss im autostart liegen)
das sind die besten tools die ich kenne bei schwieriger software die gern mal in windows Kernreise macht und dann wegen dem 1 thread limit in zeitlupe läuft.
Das tritt gern bei games auf. ist aber vom scheduler des OS abhängig und von der cpu. Was ms nicht kennt(amd) wird einfach alles auf die cpu verteilt.
Das lässt die performacnce drastisch einsacken.
Dabei ist es egal ob win 10 oder win7

 

[Holt]

"software die gern mal in windows Kernreise macht"
Diese "Kernreise "ist kein Thema der SW, sondern des Task Schedulers und passiert immer, wenn die SW nicht selbst eine Zuordnung der Threads zu den Kernen vornimmt, denn dies kann man eben auch in der SW selbst programmieren. Wie weit der Task Scheduler auf die Besonderheiten der CPU Rücksicht nimmt, kann ich nicht sagen, aber offenbar scheint der Scheduler von Windows sich bei den AMD CPUs nicht für die CCX zu interessieren, keine Ahnung ob Windows überhaupt kennen kann welcher Kern auf welchem CCX sitzt. Vermutlich nicht, denn dafür müsste es getrennte NUMA Nodes sein, aber selbst bei TR4 ist es ja einstellbar ob wenigstens die getrennten Dies als zwei NUMA Nodes erscheinen oder nur als einer. Da es unterhalb der NUMA Nodes keine weitere Unterteilungseben für solche Fälle wie die CCX gibt, dürfte der Task Scheduler auch gar nicht in der Lage zu wissen welche Kerne zusammen auf einem CCX sind.

Die beste Lösung wäre wohl, wenn der Task Scheduler von Windows die Tasks wie der von Linux nicht zigmal pro Sekunden sondern nur alle paar Sekunden verschieben würde. Wenn man bei Linux top aufruft und sich die Last der einzelnen Kerne ansieht, die dann auch auf 100% pro Kern gehen kann, so sieht man dort schön wie diese 100% dann langsam von einem Kern zu nächsten wandern, wenn nur ein Thread die CPU auslastet.