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

[ottoman]

@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/

 

[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.

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.

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.

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.

 

[HardRockDude]

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]

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.

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

( orginal )

 

[Cool Master]

Ja das sieht schon verdammt gut aus, anders kann man es nicht sagen

 

[nazgul77]

Und auch das Video dazu:

https://level1techs.com/video/2990wx-threadripper-performance-regression-fixed-windows-threadripper


Das hat nichts mit Intel zu tun sondern schlichtweg damit, dass es bisher keine CPUs mit sovielen Kernen gab.
Linux ist bedingt durch den Einsatz in Rechenzentren schon seit langem auf mehr Kerne und mehr Sockel ausgelegt gewesen.

Der von dir selbst verlinkte Artikel vermutet doch eindeutig, dass das Grundproblem ein billiger Hack des Windows-Scheduler ist, damit dieser mit den Intels mit zwei NUMA-Bereichen klar kommt. Der Hack ist billig, weil man nicht an CPUs mit mehr NUMA-Bereichen gedacht hat. Bei mehr NUMA-Bereichen, wie bei AMDs 32-Kernern, macht der Windows-Scheduler dank Hack katastrophalen Unsinn. Insofern hat es primär etwas mit der Optimierung für Intels Architektur zu tun.

Sollte es eine Intel-CPU mit mehr als zwei NUMA-Bereichen geben, wird Windows dort ebenfalls kräftig auf die Nase fallen.

This is most likely related to a bugfix from Microsoft for 1 or 2 socket Extreme Core Count (XCC) Xeons wherein a physical Xeon CPU has two numa nodes. ...

If that’s true, then that work-around to make sure this type of process stays on the “ideal CPU” in the same socket has no idea what to do when there is more than one other NUMA node in the same package to “fail over” to.

In the case of the Threadripper 2990, there are three other NUMA nodes in the socket.

As such that algorithm seems to just aimlessly shuffle threads

 

[nazgul77]

Was mich bei sowas irritiert ist das solche notwendigen Gemeinschaftsarbeiten zwischen AMD und MS nicht bereits in der Entwicklung der Prozessoren angegangen werden, sondern man erst Prozessoren released und erst danach überlegt wie man das mit Windows in Einklang bringen kann - das ist eine ziemlich kundenunfreundliche Vorgehensweise.

Es gehören zu diesem Prozess zwei Willige, die kooperieren. Ich bin mir sicher AMD sperrt sich nicht. Den Rest kann man sich erschließen.

 

[Baal Netbeck]

Bei mehr NUMA-Bereichen, wie bei AMDs 32-Kernern, macht der Windows-Scheduler dank Hack katastrophalen Unsinn. Insofern hat es primär etwas mit der Optimierung für Intels Architektur zu tun.

Danke für die Erläuterung.... jetzt wird es mir klarer was da passiert.
Dann sollte AMD mit Rome ja das Problem umgehen können wenn es jetzt nur noch Ramzugriff über den i/o Chip gibt.

Trotzdem ist es ja keine Schuld von Intel, das Microsoft das so programmiert hat.
Ich würde ihnen ja zutrauen, dass Intel Microsoft besticht um Vorteile zu erhalten, aber hier war das glaube ich nicht nötig.

Sollte es eine Intel-CPU mit mehr als zwei NUMA-Bereichen geben, wird Windows dort ebenfalls kräftig auf die Nase fallen.

So wie du es erklärt hast, wäre das logisch.
Wobei man hoffen kann, dass Microsoft so langsam doch mal auf Zen optimiert.

Angeblich soll ja das Mai update bis zu 15% mehr Leistung über den Scheduler bieten....
Aber da wäre ich skeptisch, da das noch keine Wellen geschlagen hat.

 

[nazgul77]

Naja dazu sollte man sagen dass Wendell nicht "nur YouTuber" ist. Der YouTube Kanal ist nur sein Hobby, er ist selbst Technology Consultant mit seiner eigenen Firma, und berät da nicht nur Unternehmen sondern auch Regierungsorgane. Das ist sein Tagesgeschäft und er arbeitet auch immer wieder mit diversen Industriegrößen an solchen Problemen. Für Threadripper (1) hatte er auch schon diverse Kernelfixes für Linux mit erarbeitet.

Dazu sollte man sagen, dass Microsoft nicht nur eigene Mitarbeiter, sondern auch Consultants engagiert.
Solch elementare Dinge wie der OS Scheduler sollten zumindest mit Produktlaunch neuer Prozessoren vernünftig angepasst werden. Das ist seit 2017 nicht geschehen.

Ergänzung (11. Juni 2019)

Mit wie vielen Kernen kommt denn Windows 10 derzeit zurecht? Ich frage deshalb da ich mit dem Gedanken schwanger gehe einen Ryzen R7 3700X zu kaufen falls dieser denn tatsächlich Mitte des Jahres zum Kauf angeboten wird. Da dieser Prozessor bekanntlich 12 Kerne und 24 Threads haben soll wäre es natürlich sinnvoll vorher zu wissen ob es da Einschränkungen gibt ...

Die richtige Antwort lautet: Windows 10 kommt "ab Werk" mit bis zu zwei NUMA-nodes zurecht. Stand heute. Scheduler-Patches folgen hoffentlich bald.

Ich habe keine verlässliche Angabe von AMD zur Anzahl NUMA-Nodes in Ryzen 3000 finden könne. Ich gehe aber davon aus, dass es wegen der zwei CPU-Chiplets maximal zwei NUMA domains geben wird.

 

[Cool Master]

Win 10 1905 hat einiges behoben, müsste man mal abwarten wie das aussieht. Siehe:

YouTube

An dieser Stelle steht ein externer Inhalt von YouTube, der den Forumbeitrag ergänzt. Er kann mit einem Klick geladen und auch wieder ausgeblendet werden.

YouTube-Embeds laden

Ich bin damit einverstanden, dass YouTube-Embeds geladen werden. Dabei können personen­bezogene Daten an YouTube übermittelt werden. Mehr dazu in der Datenschutzerklärung.

YouTube-Embeds laden

Datenschutzerklärung

Falls die Zeit nicht richtig beginnt bis 3:43 vor klicken. Da sind einige Folien dabei die beschreiben was MS gemacht hat.

 

[nazgul77]

@Cool Master Danke für den Link.

Sehr beeindruckend finde ich die angekündigte Reduzierung der Speicherlatenz um bis zu 30 ns. Da bin ich auf unabhängige Tests gespannt.

 

[aldaric]

@nazgul77

Schau mal im anderen Thread, da haben ein paar mit Ryzen 1st Gen schon Benchmarks mit dem Scheduler Fix laufen lassen, teilweise ein erhebliches Leistungsplus von über 10 %. Und das mit den CPU's aus 2017.... Schön wird die ganze Sache vor allem, da bei den gezeigten Benchmark-Folien von AMD der Fix noch nicht aktiv war und bei Intel die Sicherheitspatches nicht aktiv waren.

 

[nazgul77]

Oha, da fuhren die Ryzens ja Dank Microsoft bisher mit angezogener Handbremse.
Jetzt mit repariertem Windows Scheduler und den neuen schmerzhaften Fixes für Intels SMT-Lücken schwingt das Pendel ziemlich Richtung rotes Lager ...
ich rechne damit, dass unabhängige Tests mindestens eines von beiden, wenn nicht gar beides nutzen, und dann sogar bessere Ergebnisse in Leistungsvergleichen messen als AMD.