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

[frkazid]

Diese Updates sind nach wie in Kooperation mit Microsoft in Arbeit[...]

Da sollte bestimmt noch ein "vor" mit rein

Zum Thema bleibt eigentl. nur eine kleine peinliche Berührtheit übrig. 1,5 Jahre und das funktioniert immernoch nicht richtig.

 

[duskstalker]

pc master race. ich dachte win10 ist so performant und modern?

 

[Mihawk90]

Das dramatische daran finde ich, dass ein Youtuber einen fix findet, der die Leistung unter Windows richtig stellt, Microsoft aber 1,5 Jahre nach Epyc erst anfängt etwas zu ändern

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.

 

[Shoryuken94]

MacOS ist MacOS ob auf nem Mac Pro, Mini oder MacBook. Nicht mit iOS verwechseln das hat mit MacOS im Prinzip nichts zu tun außer das der Kernel ähnlich ist.

Ich wollte viel mehr auf die deutlich geringere Zahl von MacOS im Gesamteinsatz hinaus im vergleich zu Linux. Linux spielt auf dem Desktop keine große Rolle und da hat MacOS im Vergleich durchaus eine gewisse Relevanz. Schaut man aber in den Workstation und vor allem Serverbereich, holt Linux was die Verbreitung angeht enorm auf. Wenn man dann noch auf embedded Systeme schaut, zieht Linux ziemlich weit an MacOS vorbei, was die verbreitung angeht.

 

[7hyrael]

Wird wahrscheinlich so gelaufen sein: "Nanu, was möchte denn der Winzling von uns?" und auf einmal schreit die Welt nach AMD Prozessoren und bei MS wird gearbeitet...

Vermutlich, aber ist doch auch normal. In jeder halbwegs modernen Entwicklungsabteilung werden die Aufgaben heutzutage danach priorisiert wie groß das Verhältnis an Nutzen zu den Kosten ist. Wobei Nutzen eben vielschichtig zu bewerten ist, Hoher Schmerz bei wenigen durch Nichtumsetzung oder auch leichter Mehrwert für sehr viele. Einen Scheduler umzubauen klingt für mich jetzt zumindest erstmal nach etwas mit sehr viel Aufwand, hohem Risiko und gleichzeitig für nur sehr wenige überhaupt einen Nutzen, dazu ist AMD leider noch zu wenig verbreitet. Bei Linux können halt auch einfach die Leute die dringenden Bedarf haben direkt auf die Anpassungen hinarbeiten. Klar dass das schneller geht.

 

[Cool Master]

@Shoryuken94

Ah ja klar, stand da eben aufm Schlauch. Klar im Server Bereich, zumindest welche die übers Internet erreichbar sind, ist Linux die Nr. 1 und da kommt im Prinzip keiner so schnell dran.

 

[xexex]

Das Problem ist einfach , Intel hat maximal Chips mit 2 Numa Nodes gebracht dank meist Monolithic Chip Design , ergo hat Microsoft nie mit 4 Numa Nodes gerechnet .

Diese Aussage ist aus mehrfacher Hinsicht falsch. Bisher kannte man NUMA praktisch nur aus mehreren Sockeln, Serversysteme mit bis zu 8 Sockeln gab es schon seit einigen Jahren und ja auch welche mit Windows Server als Betriebssystem.

Auch mehrere Kerne waren Windows schon bekannt, Intel hat hier bereits mit Knights Landing 72 Kerne in einem Sockel gehabt.

Korrekt ist allerdings, dass man bei den jeweiligen CPUs bisher nicht mit solchen Unterschieden rechnen musste. Intel hat sich immer darum bemüht jedem Kern eine möglichst identische Anbindung an den Speicher zu geben. Deshalb hat man ja auch bei den aktuellen CPUs das Mesh eingeführt.

 

[HardRockDude]

Dass das so lange dauert, überrascht allerdings, denn Epyc existiert mit 32 Kernen, Acht-Kanal-Speicher und anderen wesentlichen Merkmalen der Plattform bereits seit 1,5 Jahren.

Es ist echt zum Schreien. Seit 1,5 Jahren ist es also nicht möglich, die volle Leistung abzurufen - sofern man Windows einsetzt. Bis das mal 100% angepasst ist, wird vermutlich soviel Zeit ins Land gezogen sein, dass Intel hardwaretechnisch aufgeschlossen hat und der potentielle gigantische Vorsprung von AMD dahingesiecht ist. (Das wäre zumindest eine pessimistische Prognose.)

 

[MK one]

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.

Solche Dinge gehören vor Release erledigt denn ein Kunde der kauft erwartet das das Produkt unter dem weitverbreitetsten OS der Welt seine volle Leistung entfalten kann - und das beim Kauf, nicht irgendwann in paar Jahren. ^^

Eine Frage .... hat Intels SMT / HT von Anfang an problemlos funktioniert ? .....

 

[SaschaHa]

So offen wie du es darstellst ist Windows gar nicht. Die meisten Probleme mit den pösen Firen kommen daher dass Benutzer einfach blind jede Meldung von Windows mit Adminrechten durchwinken.

Das stimmt, daher wäre aber ein Berechtigungssystem sinnvoll, sodass der Nutzer beispielsweise explizit bestimmte Zugriffe erlauben muss (statt dieses "Alles oder nichts"-Prinzips).

Willst du von einem offenen Windows System auf eine Diktatur wechseln?
Es ist doch ein enormer Vorteil dass du die Liraries nutzen kannst die du willst und nicht welche von denen du hoffen musst dass sie auf dem System installiert sind oder dass der Benutzer bereit ist sie zu installieren. Vielleicht macht er mit diesen Librar

Viele Programme nutzen exakt das selbe Library, müssen dieses aber immer als neue "Kopie" installieren, anstatt auf eine bereits installierte Version zugreifen zu können. Das ist in meinen Augen nicht gerade das Gelbe vom Ei. Darauf wollte ich hinaus.

 

[Mihawk90]

Das stimmt, daher wäre aber ein Berechtigungssystem sinnvoll, sodass der Nutzer beispielsweise explizit bestimmte Zugriffe erlauben muss (statt dieses "Alles oder nichts"-Prinzips).

Ich frage mich gerade ernsthaft ob du Windows jemals richtig verwendet hast. Als ob Windows kein Berechtigungssystem hätte.

Viele Programme nutzen exakt das selbe Library, müssen dieses aber immer als neue "Kopie" installieren, anstatt auf eine bereits installierte Version zugreifen zu können.

Das ist eine Sache der Programmierung der einzelnen Programme, denn wie ich bereits sagte bietet Windows sehr wohl eine Lösung dafür, sie muss halt eben auch genutzt werden.

 

[textract]

Was erwarten denn die Leute?
Windows ist halt kein skalierbares Betriebssystem.

Eigentlich sollte das Microsoft selbst ebenfalls schon seit Jahren klar sein, immerhin ist bei den paar Cores, wobei eher von Threads die Rede ist, im Enterprise-Umfeld schon sehr lange das Ende der Fahnenstange nicht erreicht.

Microsoft versucht hier ein totes Pferd weiterzureiten, das wird aber nichts und die Rolling-Release-Taktik verschlimmert das ganze.

Wenn Windows für große CPUs weiterhin und zukünftig sinnvoll weiter betrieben werden soll, dass muss ein Windows-Kernel her, der einen skalierbaren Scheduler hat.

 

[MK one]

Diese Aussage ist aus mehrfacher Hinsicht falsch. Bisher kannte man NUMA praktisch nur aus mehreren Sockeln, Serversysteme mit bis zu 8 Sockeln gab es schon seit einigen Jahren und ja auch welche mit Windows Server als Betriebssystem.

Auch mehrere Kerne waren Windows schon bekannt, Intel hat hier bereits mit Knights Landing 72 Kerne in einem Sockel gehabt.

Korrekt ist allerdings, dass man bei den jeweiligen CPUs bisher nicht mit solchen Unterschieden rechnen musste. Intel hat sich immer darum bemüht jedem Kern eine möglichst identische Anbindung an den Speicher zu geben. Deshalb hat man ja auch bei den aktuellen CPUs das Mesh eingeführt.

Was soll an meiner Aussage falsch sein ? Hat Intel 4 Numa Nodes in einem MCM Chip gebracht ? Nein , ich bezog mich eindeutig auf Intels Monolithic Design .
Das Numa Nodes , die durch CPU s in unterschiedlichen Sockeln entstehen , für Windows leichter zu erkennen sind , zumal diese auf 2 / 4 / 8 Sockel Server Mobo s sitzen die speziell darauf angepasst wurden , sollte klar sein

 

[ShadowDragon]

Viele Programme nutzen exakt das selbe Library, müssen dieses aber immer als neue "Kopie" installieren, anstatt auf eine bereits installierte Version zugreifen zu können. Das ist in meinen Augen nicht gerade das Gelbe vom Ei. Darauf wollte ich hinaus.

Hier muss man aber auch dazu sagen, wenn Microsoft 30 Versionen von z.B. DirectX 11 veröffentlicht muss man sich nicht wundern. Es ist ja nicht so als gäbe es eine Version von DirectX 11, man muss Mal auf die Build Nummern achten. Wenn ein Semikolon oder eine neue Leerzeile hinzugefügt wird ist es ein neuer build. Nur meistens ändert sich intern etwas im Sinne von hier und da Mal ein kleiner Bug fix oder eine Methode heißt anders und schon würde dieser neue build u.U. nicht mehr mit der älteren Software funktionieren. Die Software welche diesen Build als Basis nutzen funktionieren aber mit der älteren Version nicht mehr. Nur für den Nutzer scheint es so als würde da 30x Mal dass selbe installiert da es ja immer DirectX 11 heißt, dabei gibt es immer kleine aber feine Änderungen welche womöglich die Kompatibilität zerstören. (DirectX 11 dient hier als Beispiel da dort mit jedem Game ein neuer build von DirektX installiert wird)
Es gibt natürlich auch Fälle wo Windows nur eine zentrale Version der API bereitstellt oder nicht jedes Programm einen anderen Build nutzt. XD

 

[chithanh]

Eine Frage .... hat Intels SMT / HT von Anfang an problemlos funktioniert ? .....

Nein. Und die älteren unter euch werden sich vielleicht noch an den AMD Dual-Core Optimizer für Windows erinnern.

 

[DocWindows]

Viele Programme nutzen exakt das selbe Library, müssen dieses aber immer als neue "Kopie" installieren, anstatt auf eine bereits installierte Version zugreifen zu können. Das ist in meinen Augen nicht gerade das Gelbe vom Ei. Darauf wollte ich hinaus.

Wenn diese Programme wirklich eine Libraryversion nutzen die schon auf dem System installiert ist, dann wird sie nicht nochmal installiert. Die Windows Side-by-side Execution (WinSxS) kümmert sich darum.
Die "DLL Hell" ist seit Einführung dieser Technik wesentlich entschärft worden.

Ein Valider Punkt ist allerding dass die Granularität teilweise ein wenig übertrieben ist.
Ich habe z.B. derzeit 8x das Visual C++ 2008 Redistributable Paket installiert, weil sich jedes Paket in der 4. Position in der Versionsnummer unterscheidet. Das halt ich persönlich für leicht übertrieben. Gelinde gesagt.
Hier könnte man sich doch übergreifend auf Version 9.0.30729 einigen und die letzte Nummer ignorieren.
Aber gut, das ist ein altes Paket. Bei den neueren fehlt die 4. Stelle schon.

 

[Mhalekith]

Der Windows Scheduler war / ist halt schon immer scheiße im Vergleich zur Komkurrenz

 

[DocWindows]

Wenn Windows für große CPUs weiterhin und zukünftig sinnvoll weiter betrieben werden soll, dass muss ein Windows-Kernel her, der einen skalierbaren Scheduler hat.

Windows skaliert doch gut wie man hier sehen kann

Aber es ist halt problematisch wenn man ihm unbekannte Hardware mit eigenen Regeln hinwirft.
Raten was das beste Vorgehen ist kann er nicht.

 

[Volkimann]

Windows skaliert doch gut wie man hier sehen kann

Aber es ist halt problematisch wenn man ihm unbekannte Hardware mit eigenen Regeln hinwirft.
Raten was das beste Vorgehen ist kann er nicht.

Unbekannte Hardware? AMD hat an zig Firmen Engineering Samples von Ryzen & Co geschickt. Aber ausgerechnet nicht an Microsoft? Ja ne ist klar.

 

[Cool Master]

Windows skaliert doch gut wie man hier sehen kann

Und woran erkennt man nun wie Windows gut daran skaliert?

Es skaliert wohl nicht wirklich gut wie man an Threadripper sieht der unter Linux 1a läuft und unter Windows zum Teil lahmer als nen 1950X ist.