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

[MK one]

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 .
Das nicht nur der 2990 WX betroffen ist , sondern auch der EPYC hat Wendell von Level1Tech ja eindrucksvoll nachgewiesen , das es nicht sonderlich kompliziert ist die Thread hin und her Schubserei , die die Performance kostet , zu beheben hat er auch gezeigt .
AMD kann halt nicht mehr tun als ein Ticket beim Microsoft Service Team zu eröffnen und auf einen Patch zu drängen , Windows ist nicht open Source ...

 

[anexX]

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

 

[Tyr43l]

ließt sich gut, jedoch leider etwas spät, worauf der Text zum ende ja eingeht.
Bin jedoch optimistisch das zum Start der Neuen sich vieles in der Spur befinden wird.

Ich freue mich schon riesig darauf von 8 Threads wegzukommen.

 

[Cool Master]

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.

Na ja bei Linux, wo AMD sehr angagiert ist, lief es ja out of the Box. Windows ist halt Closed Source und mehr als bei MS anzuklopfen kann AMD halt nicht, vor allem waren sie bis vor ein paar Jahren im Bereich CPU halt auch niemand der etwas von MS fordern konnte.

 

[PUNK2018]

...

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

 

[SaschaHa]

... hat nichts mit dem System zu tun, sondern mit der Verbreitung.

Und MacOS ist etwa nicht verbreitet? Sorry, aber man kann es sich auch schön reden. Es hat mit der Offenheit des Systems zu tun. Diese ist zwar schön und gut, jedoch wurde sie ohne jegliche Schutzmaßnahmen implementiert.

Hier sollte man nachbessern, beispielsweise so ähnlich, wie Android es mit den Berechtigungen gemacht hat. So kann man zum Beispiel verhindern, dass beliebige Dateien oder Programme Speicherzugriff bekommen, ohne dass der Nutzer es explizit gewährleistet. Sowas wäre bereits ein effektiver Schutz gegen einige Viren, sofern der Nutzer entsprechend damit umgeht

 

[Baal Netbeck]

Und auch das Video dazu:

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

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....ein halbes Jahr, nachdem sie es schonmal angekündigt haben und eigentlich hatte ich die Meldung eher vor einem Jahr schon irgendwo gehört...da will ich mich aber nicht drauf festlegen.

Der Windows Scheduler gibt sich einfach keine Mühe mit der CCX Struktur.....ein Wunder, dass die CPUs überhaupt halbwegs laufen.

 

[Cool Master]

@PUNK2018

Genau darauf wollte ich hinaus

 

[Beitrag]

Eines verstehe ich nicht. Müsste man nicht aus dem Serverbereich z.B. bei Zwei-CPU-Systemen schon seit Jahren Erfahrung mit vielen Threads gesammelt haben? Klar, da läuft andere Software drauf, aber das Betriebssystem, dessen Scheduler damit umgehen können muss, ist dort ja sicherlich nicht gänzlich anders.

 

[Cool Master]

Und MacOS ist etwa nicht verbreitet?

Im Vergleich zu Windows? Nein. Im Vergleich zu Linux? Ja.

 

[0xffffffff]

@Volker im Artikel steht:

...das einen Zuwachs von fast 30 Prozent im 7-zip-Benchmark zeigt ...

Wo kommen die 30% her? Wenn ich dem Link folge sehe ich...

Komprimieren "Before": 38.230 KB/s
Komprimieren "After": 61.855 KB/s

De-Komprimieren "Before": 1.894.381 KB/s
De-Komprimieren "After": 2.088.300 KB/s

Die 30% passen bei keinem von beiden. Beim Komprimieren sind es ja ganze ~60% zuwachs und beim De-Komprimieren "nur" ~10%.

 

[Volkimann]

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

Als ob Microsoft keine Engineering Samples von AMD bekommen hätte.

 

[Cool Master]

Eines verstehe ich nicht. Müsste man nicht aus dem Serverbereich z.B. bei Zwei-CPU-Systemen schon seit Jahren Erfahrung mit vielen Threads gesammelt haben?

Ja, aber in der Regel laufen die Dual Sockel Systeme mit Linux, deswegen lief es da auch out of the Box so super. Dazu kommt die CPU Architektur von AMD vs. Intel die sich unterscheiden und das Problem wohl unter Windows deutlich verstärken.

 

[Mihawk90]

Es hat mit der Offenheit des Systems zu tun.

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.

Ja, aber in der Regel laufen die Dual Sockel Systeme mit Linux, deswegen lief es da auch out of the Box so super.

Darauf wollte ich übrigens vorhin raus

 

[chithanh]

Aber auch hier hat Microsoft vermutlich jahrelang einseitig auf die Intel Architektur optimiert und jetzt darf der Scheduler auseinander genommen werden.

Das Problem hat nichts mit einem wie auch immer gearteten einseitigen Fokus auf Intel zu tun. Intel-CPUs sind ebenfalls von Skalierungsproblemen verschiedenster Art betroffen.

Nein, das Problem ist allein die wenig robuste Implementierung des Windows-Schedulers. Der "Ideal CPU"-Hack ist lediglich ein weiteres trauriges Beispiel. Würde Microsoft sich um einen soliden Scheduler bemühen, dann würde nicht jedesmal das Betriebssystem zum Hindernis, wenn jemand mehr Kerne als bislang auf ein bestimmtes Problem ansetzt.

 

[DocWindows]

Windows sollte einfach generell mal die ganzen "Altlasten" loswerden und mehr optimieren. An einigen Stellen gibt es ja immer noch viele Probleme, dazu die hohe Viren-Anfälligkeit, die ganzen doppelten Laufzeit-Komponenten (Libraries), die von vielen Programmen mitinstalliert werden müssen (statt auf ein einheitliches Library zu setzen oder die Funktionalität über das System anzubieten), etc.

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 Libraries dann wieder andere Programme kaputt.

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.

Was hat denn die Offenheit des Systems mit verantwortungslosen Benutzern zu tun?
Windows ist so offen wie es nur möglich ist. Nur eben nicht quelloffen.

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.

Das ist mir auch gleich in den Sinn gekommen. Verstehe ich auch nicht.
Ich hätte es verstanden wenn man die Unterstützung zumindest bei den Servervarianten direkt gebracht hätte, aber bei den Desktopeditionen nicht. Aber das macht eigentlich auch keinen Sinn bei einem (angeblichen) OneWindows Kernel.

 

[Shoryuken94]

Im Vergleich zu Windows? Nein. Im Vergleich zu Linux? Ja.

Aber auch nur wenn man Desktopsysteme betrachtet.

 

[Mihawk90]

Was hat denn die Offenheit des Systems mit verantwortungslosen Benutzern zu tun?

Nichts und das ist genau mein Punkt.

Windows erlaubt auch nicht einfach mal eben so Zugriff auf alles durch jedes Programm, wenn aber der geneigte Nutzer einfach alles mit Adminrechten durchwinkt ist klar warum auf einmal Zugriff auf Sachen besteht, auf die kein Zugriff bestehen sollte.

 

[Cool Master]

Darauf wollte ich übrigens vorhin raus

Dann schreib das doch so

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

 

[DocWindows]

@Mihawk90: Ach so. Hab ich aus irgendeinem Grund andersrum verstanden.