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

Volker

Ost 1
Teammitglied
Registriert
Juni 2001
Beiträge
18.277
  • Gefällt mir
Reaktionen: Transistor 22
Da drücke ich den Threadripper-Besitzern beide Daumen und hoffe Microsoft bekommt das hin.
 
  • Gefällt mir
Reaktionen: 9Strike, Tapion3388, cbmik und 7 andere
Sehr schön, da hat Wendell wohl etwas Treibstoff in den Tank gekippt :)

@ottoman

Danke für den Link, den hätte ich auch gepostet.
Ergänzung ()

@Piep00

Das betrifft nur die neuen 2xxx. Die alten 1xxx laufen eigentlich ohne Probleme.
 
  • Gefällt mir
Reaktionen: DerMuuux, GTrash81, Transistor 22 und 2 andere
Bin mal gespannt ob das die Probleme von TR in DAW-Anwendungen verbessert.
 
  • Gefällt mir
Reaktionen: HardRockDude und Ctrl
Und in der Linuxwelt lief es von Anfang an ohne große Probleme.
Aber auch hier hat Microsoft vermutlich jahrelang einseitig auf die Intel Architektur optimiert und jetzt darf der Scheduler auseinander genommen werden.
 
  • Gefällt mir
Reaktionen: nazgul77, DerMuuux, derSafran und 33 andere
ottoman schrieb:
Und auch das Video dazu:

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

Volkimann schrieb:
Aber auch hier hat Microsoft vermutlich jahrelang einseitig auf die Intel Architektur optimiert und jetzt darf der Scheduler auseinander genommen werden.
Das hat nichts mit Intel zu tun sondern schlichtweg damit, dass es bisher keine CPUs mit sovielen Kernen gab. Bedenke dass hier eine CPU mehr Kerne hat als Dual-Socket Systeme vorher.
Linux ist bedingt durch den Einsatz in Rechenzentren schon seit langem auf mehr Kerne und mehr Sockel ausgelegt gewesen.
 
  • Gefällt mir
Reaktionen: ZeusTheGod, cbmik, Exey und 12 andere
@Mihawk90 Nützt leider nichts, wenn es bei MS nicht ankommt oder da erst mal im Papierkorb landet.
 
  • Gefällt mir
Reaktionen: nazgul77 und Makso
Naja die Unterstützung brauchen sie so oder so, spätestens wenn Unternehmen Ihre alten Windows Server aussortieren muss es da ja mal was geben.
 
Mihawk90 schrieb:
Das hat nichts mit Intel zu tun sondern schlichtweg damit, dass es bisher keine CPUs mit sovielen Kernen gab. Bedenke dass hier eine CPU mehr Kerne hat als Dual-Socket Systeme vorher.
Linux ist bedingt durch den Einsatz in Rechenzentren schon seit langem auf mehr Kerne und mehr Sockel ausgelegt gewesen.

Man muss ja auch beachten, dass diese Konfiguration mit mehreren Chiplets auf einem Package relativ neu ist. Das ist ja fast ein Multi-Socket-System, nur auf einem Package. Jedes Chiplet einen eigenen Speichercontroller, eigenen Cache und Ähnliches. Für ein Vier-Sockel-System war ja bisher ein Privatanwender-Windows gar nicht geeignet. Bei Linux konnte AMD entsprechende Anpassungen schon frühzeitig einfügen dank der offenen Quellcode-Basis, bei Microsoft scheint das nicht so einfach zu sein.
 
  • Gefällt mir
Reaktionen: Nikolaus117, JohnVescoya, Makso und eine weitere Person
Mihawk90 schrieb:
Das hat nichts mit Intel zu tun sondern schlichtweg damit, dass es bisher keine CPUs mit sovielen Kernen gab. Bedenke dass hier eine CPU mehr Kerne hat als Dual-Socket Systeme vorher.
Linux ist bedingt durch den Einsatz in Rechenzentren schon seit langem auf mehr Kerne und mehr Sockel ausgelegt gewesen.
Ach und von Windows gibt es keine Servervarianten?
Windows wird auch nicht in Rechenzentren verwendet? (Wenn auch nicht in dem Umfang)

Und wie bereits im Artikel steht. Microsoft bastelt jetzt seit 1,5 Jahren rum und hatte mit Sicherheit auch schon vorher ES von AMD bekommen und ihre Software zu testen und Anpassungen vorzunehmen
 
  • Gefällt mir
Reaktionen: nazgul77, Ernie75, germoney und 5 andere
Volkimann schrieb:
Ach und von Windows gibt es keine Servervarianten?
Das hab ich nicht behauptet, aber das Einsatzgebiet ist ein anderes.

Volkimann schrieb:
Und wie bereits im Artikel steht. Microsoft bastelt jetzt seit 1,5 Jahren rum und hatte mit Sicherheit auch schon vorher ES von AMD bekommen und ihre Software zu testen und Anpassungen vorzunehmen
Klar, nur dauert es eben seine Zeit den Kernel und/oder Scheduler entsprechend umzubauen und zu testen. Bei Linux ging das auch nicht von einem Tag auf den anderen sondern hat sich über die Zeit einfach entwickelt.
 
Mihawk90 schrieb:
Bedenke dass hier eine CPU mehr Kerne hat als Dual-Socket Systeme vorher.

Sockel 2011 hatte mit einigen Xeons auch schon Dual Sockel mit min. 24 Kernen (mehr wüsste ich aktuell ausm ff nicht).
 
  • Gefällt mir
Reaktionen: nazgul77 und Apple ][
Cool Master schrieb:
Sockel 2011 hatte mit einigen Xeons auch schon Dual Sockel mit min. 24 Kernen
Richtig, und 2x 24 sind bei mir 48, also ist meine Aussage doch nicht falsch wenn TR und Epyc 64 haben? ;)
 
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.

Da ist noch eine Menge Luft nach oben und meiner Meinung nach lohnt es sich auch, ab und zu mal bei 0 zu beginnen und aus den Fehlern der Vergangenheit zu lernen, anstatt diese Altlasten immer mitzuschleppen.
 
  • Gefällt mir
Reaktionen: Ernie75 und Hatsune_Miku
Wir haben bei uns in der Firma mal Epyc auf Linux und Windows getestet. Aufgabe waren Transformationen auf Finanzdaten (Speicherintensiv, pro Datensatz etwa 6GB und quasi 100% CPU Auslastung) die via JAVA RMI auf die Anzahl der verfügbaren CPU's verteilt wurden und je nach Status wurden dann neue Aufgaben zugeteilt sodass der Zustand idle weniger als 0,01% ausmachte. Das Ergebnis war, dass die Windows Maschine am Ende im Schnitt satte 12% schneller war.

Getestest wurde mit Ubuntus damals neuestem Kernel.
 
  • Gefällt mir
Reaktionen: BosnaMaster
Mihawk90 schrieb:
Richtig, und 2x 24 sind bei mir 48, also ist meine Aussage doch nicht falsch wenn TR und Epyc 64 haben? ;)
Nur das der Scheduler bei AMD schon bei 32 Kernen so seine Probleme hatte.
 
  • Gefällt mir
Reaktionen: nazgul77
SaschaHa schrieb:
Windows sollte einfach generell mal die ganzen "Altlasten" loswerden und mehr optimieren.
Haben Sie mit Win10 und dem Server-Pendant doch schon.

SaschaHa schrieb:
die hohe Viren-Anfälligkeit
... hat nichts mit dem System zu tun, sondern mit der Verbreitung.

SaschaHa schrieb:
die ganzen doppelten Laufzeit-Komponenten (Libraries)
Kommen jetzt auch bei Linux (yay Flatpack/Snaps)

SaschaHa schrieb:
die Funktionalität über das System anzubieten
WinSxS
 
  • Gefällt mir
Reaktionen: Luzifer71
Es ist eben immer wieder das Gleiche, erst wenn die Hardware verfügbar ist, kann gezielt optimiert werden. Das war bei den ersten Dual-Core-Prozessoren auch von Intel so, AMDs Bulldozer folgten mit ähnlichen Designbedingten Neuerungen und Unterschieden - gegenüber Intels HT - die Microsoft erst nachpflegen musste und nun eben bei Epyc. Dass AMD nun so schlagartig von Intels gewohnten 4k/8T oder 6K/12T auf 32K/64T springt sollte bei Microsoft früh genug mit Samples und NDA Berücksichtigung gefunden haben, dennoch sind Scheduler nicht gerade so einfach umzusetzen wie "Hello World". Auch das Testen eines geänderten Scheduler-Verhalten sollte ausgiebig durchgeführt werden, bevor man es bei seinen Kunden ausrollt. Das es bei Linux auf Anhieb besser funktioniert, ist dagegen natürlich sehr erfreulich.
 
  • Gefällt mir
Reaktionen: rg88, Nikolaus117, Wowka_24 und eine weitere Person
Mihawk90 schrieb:
Richtig, und 2x 24 sind bei mir 48, also ist meine Aussage doch nicht falsch wenn TR und Epyc 64 haben? ;)

Gibt aber schon bei 32 Kernen Problemen... 64 Kerne gibt es für TR noch gar nicht.
 
  • Gefällt mir
Reaktionen: dasfenster
Zurück
Oben