News Für Threadripper & Epyc: AMD und Microsoft arbeiten weiter am Windows-Scheduler

ottoman

Lt. Commander
Dabei seit
Mai 2008
Beiträge
1.620
@xexex
Vergleichst du hier ernsthaft Datenbanken mit Rendering Tools? Natürlich sollten sich DBs um sowas wie NUMA kümmern. Das sollte klar sein. Immerhin wird auf einem einzigen großen Datensatz gearbeitet. Aber doch nicht Programme wie z.B. ein Renderer, wo jeder Thread komplett für sich allein und nur mit einem kleinen Teil der Daten arbeiten kann. Da sollte man doch vom OS verlangen können, dass es in so einem Fall nicht komplett versagt. Ein Renderer hat nämlich überhaupt keinen Grund, NUMA Logik zu implementieren. Außer er möchte den verbuggten Windows Scheduler berücksichtigen.

Du scheinst auch wieder vergessen zu haben, was du in deinem letzten Beitrag geschrieben hast:
Das Problem würdest du genauso haben, wenn du ein 4 Sockel Xeon System nehmen würdest [...]
Ja der Scheduler von Microsoft arbeitet nicht optimal mit AMDs aktuellen Prozessoren [...]
Jetzt sind Intel Systeme auf ein mal nicht mehr betroffen, oder wie? Ist es jetzt wieder die Schuld von AMD?

Der Scheduler geht davon aus, dass die Applikation die Threadanzahl an das System anpasst und versucht die Threads auf dem "best NUMA node" zu halten und dies war bevor Epyc auf den Markt kam fast immer auch Best Practice.
Versteh ich nicht. Also ist Epyc jetzt Schuld daran, dass Applikationen nicht NUMA Aware sind und nicht mehr die Best Practice befolgt wird? Wie geht das?

Du kannst es gerne Bug nennen, nur ist es dadurch keiner.
Es ist also nicht die Schuld des Windows Schedulers, sondern jede Applikation, welche viele Threads aufmachen kann, muss NUMA Logik implementieren, um nicht 50% der Performance unter Windows zu verlieren... ?

Ohne Worte. Natürlich ist es ein Bug. Von MS wird es einen Fix geben. Damit ist die Diskussion beendet. Keine Lust mehr mit so einem Vollhonk zu diskutieren. Glückwunsch, dein Ruf eilt dir voraus. Beitrag #135 hat das gut zusammengefasst.

PS:
Der Punkt ist allerdings, dass AMD eigentlich vom Start an diesen Markt auch bedienen wollte, aber leider bis heute nicht geliefert hat.
Das sieht halt nicht jeder so: https://www.servethehome.com/amd-epyc-7371-review-now-the-fastest-16-core-cpu/
 
Zuletzt bearbeitet:

xexex

Admiral
Dabei seit
Jan. 2010
Beiträge
7.423
Vergleichst du hier ernsthaft Datenbanken mit Rendering Tools? Natürlich sollten sich DBs um sowas wie NUMA kümmern. Das sollte klar sein. Immerhin wird auf einem einzigen großen Datensatz gearbeitet. Aber doch nicht Programme wie z.B. ein Renderer, wo jeder Thread komplett für sich allein und nur mit einem kleinen Teil der Daten arbeiten kann. Da sollte man doch vom OS verlangen können, dass es in so einem Fall nicht komplett versagt.
Was ist der Unterschied dran? Ein SQL Server lässt sich so konfigurieren, dass er eine Abfrage in maximal so viele Threads aufteilt, wie ein Numa Knoten zur Verfügung hat. Ein Microsoft SQL Server würde ohne jeglichen Leistungsnachteil und ohne von dir immer wieder aufgeführte "Problematik" wunderbar auf einem Epyc System funktionieren.

Ein Renderer kann das auch! Nur der Renderer selbst kann die anstehenden Aufgaben auf eine voreingestellte Anzahl Threads aufteilen und so ein Numa System richtig nutzen. Professionelle Systeme können nicht nur mit sowas umgehen, sie lassen sich sogar auf mehrere Server aufteilen und teilen die Arbeit untereinander auf.

Versteh ich nicht. Also ist Epyc jetzt Schuld daran, dass Applikationen nicht NUMA Aware sind und nicht mehr die Best Practice befolgt wird? Wie geht das?
Wieso versuchst du immer einen "Schuldigen" zu finden? Die Applikationen sind so wie sie sind, manche können mit Numa umgehen, manche können damit gar nicht umgehen, manche stürzen dabei ab oder können gar nicht alle Threads einer CPU nutzen (Handbrake).

Bisher waren Numa Systeme in Datacentern zu finden, häufig auch in Rendefarmen oder Computing Clustern. Numa ist letztlich auch nur der "kleine Bruder" von verteilten Systemen, auch die gibt es nicht erst seit heute.

Dort wird aber auch hauptsächlich Software eingesetzt, die dafür ausgelegt wurde und dort hat der Epyc auch keine Probleme, egal welches Betriebssystem zum Einsatz kommt.

Probleme sind entstanden weil man ein Numa System für "jedermann" auf den Markt gebracht hat und hier Software einsetzt die darauf nichts verloren hat. Ein schönes Beispiel dafür ist das bereits genannte und beliebte Handbrake.
1547765808556.png


Aus einer Anwendung die sich einen Dreck um das unterliegende System schert, wird auch der beste Scheduler nicht das Optimum herausholen können. Wenn ich mich nicht irre muss man sogar Handbrake mehrfach starten wenn man alle Kerne von einem Threadripper nutzen will (zumindest was es mal so) und das sind Applikationen die eigentlich auf von solchen Systemen am meisten profitieren würden!

Ich wiederhole es gerne noch einmal! Ja! Der Scheduler von Microsoft läuft nicht optimal mit Applikationen die von Numa nichts verstehen, weil er davon ausgeht, dass die Menschen die solche Systeme konfigurieren wissen, wie man sie optimal nutzt.

Eine Lösung von Microsoft wird nie das Optimum aus den Systemen herausholen können, weil es bei einem Epyc nie das Optimum geben wird. Alleine der Punkt der Speicheranbindung bleibt bei der aktuellen Generation unoptimierbar für eine Systemkomponente die keinerlei Informationen darüber hat welche Anforderungen die Applikation gerade benötigt.
1547766241019.png

https://www.anandtech.com/show/11544/intel-skylake-ep-vs-amd-epyc-7000-cpu-battle-of-the-decade/12

Dies wäre die Sache der jeweiligen Anwendung es zu optimieren und wie ich bereits sagte kann jede Anwendung es auch selbst tun. Im Fall deiner problematischen Anwendung die ein Rendertread mit 32 Prozessen startet, hätte sie auf einem Numa System mit 4x8 Cores eben 4 Renderthreads mit je 8 Prozessen starten sollen. Das von dir genannte "Problem" wäre so nie aufgetreten.

Alternativ kann auch nur eine Applikation die einen hohen Speicherdurchsatz benötigt die Prozesse auf unterschiedliche Numa Knoten aufteilen. Das wird ein Scheduler niemals selbst können, deshalb auch die Tests wo ein Epyc mit zwei Kanälen nicht langsamer war wie ein Epyc mit 8 Kanälen.

Fazit:
AMD ist nicht dumm und sie haben erkannt, dass man das Problem auf der Softwareseite auch in 10 Jahren nicht optimal lösen können wird. Deshalb hat man die Lösung nun entsprechend optimiert und in ein paar Jahren redet sowieso niemand mehr davon.

Microsoft wird hier und dort bestimmt etwas optimieren, wer nun einen Wunderpatch erwartet, kann jedoch lange drauf warten.

Die Schuld einzig Microsoft in die Schuhe zu schieben ist einfach, jedoch gibt es solche Systeme nicht seit heute, die Unzulänglichkeiten der Software sind ebenfalls lange bekannt und trotzdem kam ein Stück Hardware auf den Markt so wie es nun mal kam. Für mich ist die Schuldfrage deshalb irrelevant, über die bevorstehenden Probleme habe ich bereits diskutiert, da sind die Epyc CPUs gerade mal vorgestellt worden. Mir sind die Nachteile von einem solchen System seit Jahren bekannt.
 
Zuletzt bearbeitet:

HardRockDude

Commander
Dabei seit
Juli 2009
Beiträge
2.062
Das Ganze ist so oder so ein interessantes Problem. Microsoft und AMD arbeiten durch die Xbox bereits seit vielen Jahren zusammen und kennen sich daher als Partner. Man kann sich also sehr gut vorstellen, dass das Verhältnis gut sein muss und deswegen auch schneller Fortschritte erzielt werden müssten, einfach weil der Informationsfluss schon da ist.

Nvidia mit Raytracing und DLSS sieht zur Zeit auf ähnliche Weise kein Land, weil die Techniken von quasi keiner Software unterstützt werden. Da ist die Bandbreite potentieller Softwareentwickler aber auch zig mal größer.
 

MK one

Captain
Dabei seit
März 2017
Beiträge
3.079
Direct ML mit ML Supersampling sehe ich als deutlich besser an als DLSS , witziger weise hat NV da eng mit Microsoft zusammengearbeitet und jetzt scheint die Radeon VII den größten Nutzen draus zu ziehen , damit kann die Radeon VII ( und Vega 64 / 56 ) einen Gutteil ihrer Compute Leistung per Async Shader auf den Boden bringen , während Direct bei NV direct die Tensor Cores Nutzen kann .
Das es eine recht freie Schnittstelle ist , die alle DX12 Karten benutzen können hat sie ein höheres Durchsetzungsvermögen als das NV only DLSS.

upscaleblog_575px.jpg
+
Links ML Supersampling und rechts Bilinear Supersampling ( ML steht für Machine Learning ) in der Vergrößerung
twocars.png

( orginal )
 
Top