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

[SaschaHa]

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

Meistens wird man nur beim Programmstart gefragt, ob man deren Ausführung erlauben möchte. Das war's. Während der Ausführung habe ich es noch nicht erlebt, dass ich gefragt werde, ob ich beispielsweise den Speicherzugriff nun (oder von jetzt an) erlauben möchte. Das wäre jedoch sinnvoll.

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

Genau das kritisiere ich ja. Nur, weil ein paar Zeilen geändert wurden, sollen gleich die ganzen Pakete separat installiert werden? Das ist doch sinnlos. Wie wäre es mal mit einer Abwärtskompatibilität für solche Änderungen?

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.

Redistributables, danke! Genau die wollte ich als Beispiel anführen, aber mir fiel der Name nicht ein

 

[DocWindows]

Aber ausgerechnet nicht an Microsoft? Ja ne ist klar.

Ich weiß nicht wer wem etwas geschickt hat. Ich arbeite weder bei AMD noch bei Microsoft.
Daher finde ich es auch merkwürdig dass AMD und Microsoft jetzt plötzlich zusammen am Scheduler arbeiten wollen, obwohl sie das eigentlich vor Release der CPU hätten machen müssen.

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.

Ich habe doch geschrieben dass AMDs Weg anscheinend Probleme bereitet. Das liegt aber nicht daran dass es zu viele Kerne wären, sondern daran dass die Logik der Ansteuerung und optimalen Nutzung offensichtlich anders ist als bei anderen CPUs. 8 CPUs mit je 20 Kernen scheinen ganz gut zu funktionieren. Die sind zwar nicht alle ausgelastet, aber ich kenne den Workload auch nicht.

 

[Retro-3dfx-User]

MS sollte eventuell auchmal eine Funktion implementieren wo man direkt im Taskmanager für Programme echte und HT Kerne differenziert zuteilen kann und sie auch weiß sofort zu unterscheiden.

Für diverse sachen würde ich doch gerne echte Cores statt HT gedöhns zuteilen, oder sowas sogar einstellen können das nur echte oder HT für dies oder jenes verwendet werden.

 

[xexex]

Was soll an meiner Aussage falsch sein ?

Intel hat maximal Chips mit 2 Numa Nodes gebracht

Intel hat nie "normale" CPUs mit mehreren Numa Nodes gebracht, allerdings Systeme mit bis zu 8 Numa Nodes! Die einzigen CPUs von Intel die sich auf bis zu 4 Numa konfigurieren liessen, war die gesamte Phi Plattform.

https://colfaxresearch.com/knl-numa/

Microsoft ist Numa also seit Jahren bekannt, sowohl in einem, als auch in mehreren Packages. Ungewohnt war nur die Art wie AMD die Chips aufgebaut hat. Bei Intel war die Sache immer eindeutig, entweder hat die Last möglichst auf einem Socket zu hängen (Multisocket) oder man hatte 2-4 Numa Nodes in einem Chip, die sehr homogen an den Speicher angebunden waren (Phi).

Woher du allerdings die zwei Numa Nodes bei Intel herholst, ist mir absolut schleierhaft.

 

[Cool Master]

Ich habe doch geschrieben dass AMDs Weg anscheinend Probleme bereitet.

Und das ist halt nicht der Fall. Das Problem liegt an MS und nicht AMD, hat Wendell ja super nachgewiesen.

 

[Majestro1337]

Im Artikel steht nur "Windows" - ist denn davon auch die Server-Variante betroffen?
Wenn nein, dann wundert mich dass kaum. Der Kreis der TR Besitzer ist ja nun nicht dort groß und der Anteil an Linux-Nutzern sicher überdurchschnittlich. Wenn ja, dann fände ich es schon überraschend, da Epyc ja ganz gut läuft und ein entsprechender Server damit per default mit Linux laufen muss und MS sich dann selbst ins Aus schießt...

 

[Mihawk90]

Wie wäre es mal mit einer Abwärtskompatibilität für solche Änderungen?

Abwärtskompatibilität ist doch nicht die Aufgabe des OS. Das ist bei Linux nicht anders. Wenn deine Distro der Wahl die Lib nicht in der passenden oder einer kompatiblen Version bereit stellt hast du genau dasselbe Problem.
Kompatibilität der Lib ist Aufgabe des Lib Maintainers und desjenigen der sie nutzt. Und klar, DX ist auch von MS, aber das Problem gibt es ja nicht nur dort.

 

[ottoman]

Intel hat nie "normale" CPUs mit mehreren Numa Nodes gebracht, allerdings Systeme mit bis zu 8 Numa Nodes! Die einzigen CPUs von Intel die sich auf bis zu 4 Numa konfigurieren liessen, war die gesamte Phi Plattform.
https://colfaxresearch.com/knl-numa/

Microsoft ist Numa also seit Jahren bekannt, sowohl in einem, als auch in mehreren Packages. Ungewohnt war nur die Art wie AMD die Chips aufgebaut hat. Bei Intel war die Sache immer eindeutig, entweder hat die Last möglichst auf einem Socket zu hängen (Multisocket) oder man hatte 2-4 Numa Nodes in einem Chip, die sehr homogen an den Speicher angebunden waren (Phi).

Woher du allerdings die zwei Numa Nodes bei Intel herholst, ist mir absolut schleierhaft.

Da gibt es einen Absatz im verlinkten Artikel aus dem ersten Beitrag:

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. In the past (with Xeon V4 and maybe V3), one of these NUMA nodes has no access to I/O devices (but does have access to memory through the ring bus).

 

[DocWindows]

Das Problem liegt an MS und nicht AMD

Ja, MS Windows hat ein Problem damit. Mit anderer Vielkerntechnik nicht. Darum arbeiten doch Microsoft und AMD an dessen Lösung. Hätten sie aber schon viel früher machen müssen. Ist aber auch nicht das erste Mal dass AMD Dinge anders macht als es vorher gemacht wurde. Sowas ähnliches hatten wir bei Bulldozer/Piledriver ja auch schon. SMT vs. CMT, Modulkonzept.

 

[xexex]

Da gibt es einen Absatz im verlinkten Artikel aus dem ersten Beitrag:

Hast recht! Hatte ich gar nicht auf dem Schirm!

Therefore, MCC and HCC have two memory controllers per CPU socket whereas LCC CPUs has one only.
COD can be enabled on MCC and HCC due to double number of memory controllers.
The NUMA node with enabled COD is split into two NUMA domain and then – each owns half of the cores, memory channels and last level cache. Each domain, which includes memory controller and cores, is called a cluster.

Ist aber auch ein optionales Feature gewesen und auch hier hatte man zwei ebenbürtige CPU Teile.

With Cluster on Die each Memory controller now serves only half of the memory access requests thus increasing memory bandwidth and reducing the memory access latency. And obviously two memory controllers can serve twice as much memory operations.
https://www.starwindsoftware.com/blog/numa-and-cluster-on-die

 

[Salutos]

Wie dieses Beispiel mal wieder bestätigt, interessieren sich die großen, guten Intelpartner, wie eben Microsoft einer ist, einen Dreck darum, für Alternative Hardwarehersteller wie AMD ihre Software zu optimieren.

Würde es kein Linux geben, das es uns ermöglicht Unterschiede zu erkennen, so würden diese Probleme nie behoben.

 

[ghecko]

Im Artikel steht nur "Windows" - ist denn davon auch die Server-Variante betroffen?
Wenn nein, dann wundert mich dass kaum. Der Kreis der TR Besitzer ist ja nun nicht dort groß und der Anteil an Linux-Nutzern sicher überdurchschnittlich. Wenn ja, dann fände ich es schon überraschend, da Epyc ja ganz gut läuft und ein entsprechender Server damit per default mit Linux laufen muss und MS sich dann selbst ins Aus schießt...

Search no further:
https://www.phoronix.com/scan.php?page=article&item=windows-server-2990wx&num=1
https://www.phoronix.com/scan.php?page=article&item=windows2019-linux-bsd&num=1
https://www.phoronix.com/scan.php?page=article&item=2990wx-linwin-scale&num=1
Wie man sieht, ist Win10 in den meisten Benchmarks sogar schneller auf TR als die Server-Variante.

 

[Volkimann]

Ja, MS Windows hat ein Problem damit. Mit anderer Vielkerntechnik nicht. Darum arbeiten doch Microsoft und AMD an dessen Lösung. Hätten sie aber schon viel früher machen müssen. Ist aber auch nicht das erste Mal dass AMD Dinge anders macht als es vorher gemacht wurde. Sowas ähnliches hatten wir bei Bulldozer/Piledriver ja auch schon. SMT vs. CMT, Modulkonzept.

Wie sollen sie auch ohne Lizenz- oder Patentverletzungen es auch sonst umsetzen? Sonst würde es nur wieder heißen das AMD ja nur kopiert hätte.

Und wie man an Meltdown & Co sieht ist es vielleicht ganz gut gewesen einen anderen Weg zu gehen.

Und wenn AMD an Microsoft (den OS Marktführer wird man wohl kaum ausgelassen haben) die Engineering Samples schickt mitsamt Doku der Funktionsweise und sagt "das wird unser Produkt, so muss der Scheduler laufen" dann muss Microsoft sich da ransetzen.
Wer weiß wie lange schon AMD an MS herangetreten ist um ihre eigenen Leute daran arbeiten zu lassen und MS hat es vorher nicht zugelassen.

 

[DocWindows]

Wie sollen sie auch ohne Lizenz- oder Patentverletzungen es auch sonst umsetzen? Sonst würde es nur wieder heißen das AMD ja nur kopiert hätte.

Gegen eine gute Kopie hätte zumindest ich nichts einzuwenden gehabt.
Und da sie vorher mit Phenom schon "klassische" CPUs hatten, wüsste ich nicht was für Patente da verletzt werden würden.

Und wie man an Meltdown & Co sieht ist es vielleicht ganz gut gewesen einen anderen Weg zu gehen.

Und wie man am Erfolg von Bulldozer/Piledriver und der Abkehr von dessen Konzept mit den Ryzen CPUs sieht, war es vielleicht doch eher nicht so gut einen anderen Weg zu gehen.

Wer weiß wie lange schon AMD an MS herangetreten ist um ihre eigenen Leute daran arbeiten zu lassen und MS hat es vorher nicht zugelassen.

Ich weiß es nicht, und du anscheinend auch nicht. Ich hätte mir aber gewünscht das BEIDEN Firmen mehr daran gelegen gewesen wäre dem Kunden eine möglichst gute Erfahrung mit den CPUs ab Tag 1 zu bereiten.

Ich bin kein Freund davon den Schwarzen Peter bei so einer Gemeinschaftsarbeit nur einer Seite zuzuschieben.
Das ist viel zu selten gerechtfertigt.

 

[xexex]

Und wenn AMD an Microsoft (den OS Marktführer wird man wohl kaum ausgelassen haben) die Engineering Samples schickt mitsamt Doku der Funktionsweise und sagt "das wird unser Produkt, so muss der Scheduler laufen" dann muss Microsoft sich da ransetzen.

Microsoft hat ungefähr 5 Jahre benötigt um Intels Turbo Boost 3.0 Technik ins System zu implementieren. Wenn AMD irgendwas entwickelt hat und zu Microsoft gesagt hat: "Hier macht was draus!". Konnte nur das jetzt bekannte Ergebnis dabei herauskommen.

Der Fehler kann man sich hier jezt gegenseitig zuschieben, nur bringt es niemandem was. Das Problem hat AMD nun mit dem zusätzlichen IO Chip umschifft und man hätte sich sowas auch zum Start vorstellen können, dann wäre die Problematik gar nicht erst aufgetreten.

 

[MrZweistein]

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

 

[Shoryuken94]

@MrZweistein

Also ich hatte bisher keine Probleme mit 16 Kernen und 32 Threads... Kommt natürlich immer auch ein wenig auf die Software an, die man so verwendet. Aber allgemein Windows hat recht wenig Probleme mit 12 Kernen

 

[Majestro1337]

@ghecko : das ist ja desaströs! Da sollte jemand dringend die prio von dem Ticket erhöhen!

 

[mkdr]

Ach und von Windows gibt es keine Servervarianten?
Windows wird auch nicht in Rechenzentren verwendet? (Wenn auch nicht in dem Umfang)

Verwendet Microsoft für ihre eigene Cloud eigentlich Windows Server? Ich denke nicht...

 

[MK one]

Microsoft hat ungefähr 5 Jahre benötigt um Intels Turbo Boost 3.0 Technik ins System zu implementieren. Wenn AMD irgendwas entwickelt hat und zu Microsoft gesagt hat: "Hier macht was draus!". Konnte nur das jetzt bekannte Ergebnis dabei herauskommen.

Der Fehler kann man sich hier jezt gegenseitig zuschieben, nur bringt es niemandem was. Das Problem hat AMD nun mit dem zusätzlichen IO Chip umschifft und man hätte sich sowas auch zum Start vorstellen können, dann wäre die Problematik gar nicht erst aufgetreten.

was aber zusätzlichen Design aufwand bedeutet hätte und wer packt schon 2 Chips vom selben Fertigungsprozess in ein MCM Design wenn er das auch mit einer Maske erledigen kann , das I/O Die Konzept ist ja nicht neu , nur macht es halt bei 7 nm mit 14 nm I/O Die wirtschaftlich gesehen am meisten Sinn , einerseits existiert auch weiterhin eine Abnahmeverpflichtung gegenüber GF , andererseits profitiert der I/O Anteil nicht großartig von einem Shrink und drittens , je kleiner der Die in einem neuen Verfahren ist , desto wahrscheinlicher ist er OK = höherer Yield
Aus Wirtschaftlicher Sicht hat AMD Intel abgehängt , je höher die Kernzahl , desto deutlicher .
Der Yield war und ist (?) der größte Knackpunkt bei Intels 10 nm neben der Taktbarkeit , bleibt abzuwarten ob Intel es tatsächlich auch bei hohen Taktraten hinbekommt , angekündigt hatten sie es ja schon so oft .....