Last nicht gleichmäßig auf CPUs verteilt

[Müs Lee]

Moinsen,

mir ist eben etwas merkwürdiges aufgefallen. Auf meiner Workstation werden große Tasks anscheinend nicht gleichmäßig auf die beiden Prozessoren verteilt. Das Bild zeigt die Auslastung während einer Struktursimulation (Optistruct) mit 32 worker threads, die alle auf einen Prozessor gequetscht werden und auch die HT-Kerne belasten, anstatt die physischen Kerne des ersten Prozessors zu belegen. Laut https://www.anandtech.com/show/15483/amd-threadripper-3990x-review/3 und anderen Quellen hatte Windows ja desöfteren mal Querelen mit hohen Kernanzahlen, aber da hier W10 Pro for Workstations läuft, sollte das eigentlich kein Problem mehr sein. Was kann man da tun, außer HT zu deaktivieren?

 

[burglar225]

Du hast 32 Worker-Threads und 32 Kerne (+/-) werden ausgelastet. Insofern ist doch alles bestens?

 

[Powl_0]

Denke mal das ist gewollt. Kommunikation zwischen Sockeln kostet viel Latenz. Wenn alle Tasks eines Programs auf einen Sockel passen, wird Windows die also lieber beisammen lassen. Und nachdem du 32 Threads pro Sockel hast, sieht Windows da noch keinen Bedarf, auf den zweiten Sockel zu schwappen.

Wie siehts denn mit zB 40+, 50+ Workern aus?

 

[Müs Lee]

@burglar225 Nicht ganz, da die 16 HT-Kerne von NUMA-Node 1 die Arbeit der echten Kerne von Node 0 übernehmen. Das kostet Leistung.
@Powl_0 Ist absolut nachvollziehbar, aber es kostet mehr Leistung, die HT-Kerne ackern zu lassen anstelle der echten Kerne. Wäre es sinnvoll, UMA anstatt NUMA zu verwenden? Oder kann man Windows beibringen, das "gerecht" zu verteilen? Mit anderen Zahlen als 16/32/64 Threads habe ich noch nicht getestet, mache ich bei Gelegenheit mal.

 

[burglar225]

Nicht ganz, da die 16 HT-Kerne von NUMA-Node 1 die Arbeit der echten Kerne von Node 0 übernehmen. Das kostet Leistung.

Aber die Arbeit von 32 Working-Threads auf 64 Kerne zu verteilen kostet mindestens genauso viel. Im Zweifelsfall hast du dann sogar noch mehr Kontextwechsel. Zudem, wie Powl schon gesagt hat, kostet der Socket-Swap nochmal mehr, wie ein einfacher Kontextwechsel der Register.
Ich kann da jetzt aber auch nicht ewig viel zu sagen zugegebenermaßen, so tief bin ich in der Materie auch wieder nicht drinne.

 

[Hallo32]

Einfache Antwort: Testen

Das Verhalten hängt sehr stark von der Art der Last ab.

 

[Müs Lee]

@burglar225 Die 32 worker threads würden nicht auf 64 Kerne verteilt werden. Es wären 16+16 echte Kerne anstatt 16 echte und 16HT-Kerne. Ich bin bei Mehrsockelsystemen auch nicht sonderlich bewandert. Aus bisheriger Erfahrung kann ich lediglich feststellen, dass bei Einsockelsystemen die Leistung stark einbricht, wenn HT-Kerne die Aufgabe der echten Kerne übernehmen müssen. Aber möglicherweise weiß Windows mehr und vermeidet noch höhere Leistungseinbußen zwischen den Sockeln

 

[burglar225]

Die 32 worker threads würden nicht auf 64 Kerne verteilt werden. Es wären 16+16 echte Kerne anstatt 16 echte und 16HT-Kerne.

Tut mir Leid, ich kann dir da jetzt gerade nicht folgen. Was heißt "würden"? Wenn du HT deaktivierst? Der Performancegewinn dürfte allerhöchtens minimal sein und kostet dich halt 50% der Threads.
Insgesamt habe ich auch immer noch nicht verstanden, was genau dein Problem ist. Wie schon gesagt, du hast 32 Threads und 32 Kerne werden ausgelastet. Noch dazu schafft der Windows-Scheduler es offensichtlich von alleine die Arbeiten auf einem einzelnen Socket durchzuführen. Klingt für mich so, als würde alles perfekt funktionieren.

 

[Müs Lee]

Die Sockel/Prozessor in diesem System haben 16 vollwertige Kerne und 16 HT-Kerne. Die HT-Kerne sollen "administrative" Tätigkeiten übernehmen wie bspw. Datenbeschaffung. Werden die HT-Kerne mit den Rechenaufgaben der echten Kerne bombardiert, geht die Leistung in die Knie, da sie dafür nicht ausgelegt sind. Prinzipiell schafft es Windows, die Last auf die echten Kerne zu verteilen und Leistungseinbußen zu umgehen, präferiert aber bei mehreren Sockeln anscheinend, dies eben nicht zu tun. Hier wird eben die Last auf 16 echte Kerne und 16 HT-Kerne verteilt anstelle sie auf 32 echte Kerne zu legen, wie ich es erwarten würde.

 

[Müs Lee]

So, ohne HT insd bei einer ganz ähnlichen Aufgabe mit dem gleichen Programm und ebenfalls 32 Workerthreads alle physischen Kerne vollständig ausgelastet. Ist es denn echt nicht zu bewerkstelligen, dass das gleiche Verhalten auch mit HT auftritt?

 

[teleguy]

Die Prozessaffinität einfach manuell festlegen?

Geht z.B. mit dem Windows Taskmanager über Details->Zugehörigkeit festlegen.

Muss man allerdings bei jedem Programmstart wiederholen.
Deshalb kann man das auch per Batch File machen.
https://www.tenforums.com/performance-maintenance/47607-affinity-command-cmd.html

Gibt auch Tools, die das erledigen z.B. Process Lasso. Damit gilt das dann auch dauerhaft.

 

[Müs Lee]

Ah, das wäre einen Versuch wert. Danke für den Hinweis