Test Ryzen Threadripper 2000 im Test: 32 Kerne sind verrückt, 16 sehr gut nutzbar

[Sun_set_1]

Dieser wurde zu einem späteren Zeitpunkt jedoch auch obsolet, und von Intel gab es damals auch eine eigene SpeedStep Software, weil Microsoft die Mechanismen nicht direkt implementiert hat.

Ich möchte an dieser Stelle keinen Schuldigen suchen, es wurde bereits angekündigt, dass Microsoft mit AMD hier in der Zukunft noch Optimierungen durchführen werden. Ärgerlich ist nur die Tatsache, dass man die Probleme vom Ryzen Start unnötigerweise wiederholt.

Naja, ich würde fast sagen bei Ryzen-Start war es weniger schlimm. Die Zielgruppe dort konnte ja zumindest über die schnellen RAM's viel ausgleichen. Wie schon häufiger geschrieben, wird dies im professionellen Umfeld aber eher nicht erfolgen.

Ich denke, dass es eine rein wirtschaftliche Entscheidung war. Einig dürften wir uns alle darüber sein, dass es kein unmögliches Ding gewesen wäre, alle Vier parallel anzubinden. Hätte natürlich dann auch wahrscheinlich eine neue Chipsatzgeneration erfordert, aber auch das wäre machbar gewesen.

Ich denke man wusste ganz genau, das man in etwa im Intel-Leistungsgefüge landen wird. Dazu unterbietet man den Preis deutlich und hat aus dieser Kombination heraus, ein wettbewerbsfähiges Gesamtpaket. Im nächsten Refresh kann man dann noch mal hohe zwei-stellige Prozentwerte rausholen, ohne viel am Design selbst zu ändern. Vier statt zwei Anbindungen, neue Chipsatzgeneration. Et voilà.

Im Prinzip das, was Intel immer wieder vorgeworfen wird. Man springt nicht höher, als man muss. Da sich so natürlich Entwicklungskosten reduzieren und Gewinne maximieren lassen.
Das kann man moralisch verwerflich finden, ich denke aber, das ist ein (leider) normaler Ablauf in einem kapitalistischen Wirtschaftssystem.

 

[ghecko]

Du siehst doch bei Linux, dass AMD sich lange vorher um den Software-Support gekümmert hat. Dort müssen sie sogar alles selbst machen, und es klappt.

Offensichtlich wollte Microsoft hier nicht und braucht erst den Druck der Kunden, bis sie in Wallung kommen.

Linux hat keine besonderen Threadripper-Anpassungen erfahren.
Ich verfolge die wichtigsten Neuerungen der Kernel ziemlich genau, wenn da seitens AMD optimierungen bezüglich Threadripper eingeflossen wären, hätte ich davon gelesen.
Es ist also nicht so, das die Kernelentwickler im Gegensatz zu Microsoft sich um Threadrippersupport bemüht haben. Der Kernel kommt einfach besser mit vielen Threads zurecht. Alle relevanten Supercomputer laufen unter Linux, gegen diese Prozessorcluster sind die 64 Threads dieses Prozessors nicht gerade eindrucksvoll.
Man könnte bestimmt einen 4 Jahre alten Kernel nehmen, die Benchmarks wiederholen und würde dasselbe Gefüge sehen.

 

[MK one]

seh ich auch so , Microsoft läßt sich immer mehr Zeit, andererseits läuft Windows auch auf einer sehr großen Anzahl von PC s , Änderungen an einer Stelle können Probleme an anderer verursachen .

Der Unterschied ist halt , AMD kann frei an/bei Linux rumwerkeln lassen , bei Microsoft geht das nicht .

 

[HaZweiOh]

@ghecko: bei Linux läuft es ja auch.
Es ist doch völlig klar, dass Windows hier ein Problem hat, was Microsoft lösen muss, und das mindestens 12 Monate bekannt ist. Auf AMDs Seite sieht man anhand von Linux, dass AMD lange vor dem Launch Patches einreicht. Das kann man regelmäßig bei Phoronix lesen.

Microsofts Kunden zahlen einen Haufen Geld dafür. Und jetzt müssen sie ihren Dienstleister mit Benchmark-Balken unter Linux davon überzeugen, seine Arbeit zu machen. Die Standard-Ausrede "anderes war wichtiger" kommt doch immer.

 

[Sun_set_1]

Der Unterschied ist ganz einfach die Verbreitung. Man kann Microsoft auch nicht vorwerfen, die Prio zunächst auf die 80-90% Intelanwender zu legen. AMD ist halt der kleinere Wettbewerber und daher auch bei Microsoft weniger wichtig als Intel.

Wie @xexex sagte, abwarten und Tee trinken was da noch kommt. Es jetzt Microsoft vorzuwerfen, ist eventuell etwas verfrüht. Wenn es sich in einem Jahr nicht geändert hat, dann ist es sicherlich berechtigte Kritik.

Aber ganz generell, bleibt bei mir dieses Gefühl, wenigstens zweimal pro Jahrzent damit konfrontiert zu werden, dass der MS Kernel nur mit extra Arbeit dazu in der Lage ist, viele Kerne vernünftig zu adressieren.

Wieso MS-Server hingegeben keine Probleme mit 256 Cores und X-Sockeln zu haben scheinen- bleibt dabei ein Mysterium.

 

[Heschel]

und wir hypen kerne, kerne, kerne...
und dann geben wir zu das zu viele kerne nicht richtig funktionieren.

ein produkt, das niemand braucht.
das wird noch jahre brauchen bis es mal wirklich anständige software dafür gibt.
und trotzdem werden leute dadrauf reinfallen, das neumodische kern-gehype sei dank.

Wenn Du nur am PC nur Spiele spielst, brauchst Du auch keine 32 Kerne. Der TR ist auch nicht zum spielen gedacht, sondern ist für andere Anwendungen interessant. Aber sage uns mal, bist Du immer noch mit einem single-Core CPU ala Pentium 3 oder 4 unterwegs?

Ach ja, zur Software: Wozu sollten Software-Entwickler für mehr Kerne optimieren, die es garnicht gibt? Vielleicht optimiert man die Software gerade weil es die Technik gibt, die es auch nutzen kann? Früher hieß es ja auch, dass ein Dual-Core beim spielen immer noch besser ist als ein Quad-Core. Als sich der Quad-Core durchgesetzt hat, hat sich auch die Software (Spiele und Anwendungen) verändert und der Dual-Core fing an zu schwächeln.

 

[chithanh]

Wieso MS-Server hingegeben keine Probleme mit 256 Cores und 4 Sockeln zu haben scheint- bleibt dabei ein Mysterium.

Das hängt auch vom Workload ab. Server-Workloads skalieren prima auf viele Kerne/Threads, da hatte Microsoft schon lange Zeit auf die Anforderungen der Anwender zu reagieren. Die Workstation/HEDT-Workloads treten jedoch erst jetzt auf 32C/64T+NUMA auf.

 

[Sun_set_1]

...

Ja, aber das bedeutet doch im Umkehrschluss, dass viele Optimierungen nicht auf den Endanwender Kernel/Sheduler übertragen wurden. Da stellt sich doch die Frage: Warum?

1. Entweder weil die Verbesserungen für Server potenzielle Leistungsnachteile für Endanwender bedeuten könnten.

2. Oder man wirklich zwei (Grund-?)verschiedene Kernel-Versionen für Windows pflegt. Aber das wäre doch ein unnötig hoher Aufwand ohne wirklichen Nutzen. Deshalb leuchtet mir das nach wie vor nicht ganz ein.

3. Microsoft hat ganz einfach über Jahre hinweg stark auf Intel-Architektur hin optimiert. Und wir sehen nun das Endergebnis.

An die Intel-Hasser:
Punkt 3 ist / wäre Microsoft aus wirtschaftlichem Standpunkt heraus ganz sicher nicht vorzuwerfen!

 

[chithanh]

@Sun_set_1
Nein, es geht einfach darum, dass die Workloads an sich unterschiedlich sind.

Workloads die typischerweise auf Datei-/Datenbank-/Webservern auftreten skalieren gut. Workloads die eher auf HEDT/Workstation-Systemen auftreten wie viele Dateien erzeugen und löschen, viele kurzlebige Prozesse starten, Kommunikation zwischen Threads über NUMA-Grenzen hinweg, usw. liefen bislang auf wenigen Kernen/Threads gut. Aber es hat sich bei Microsoft bislang keiner dafür interessiert, das auch auf vielen Kernen/Threads performant zu machen. Das Ergebnis sehen wir immer wieder (mein Beitrag #461 enthält mehr Beispiele).

 

[xexex]

Naja, ich würde fast sagen bei Ryzen-Start war es weniger schlimm. Die Zielgruppe dort konnte ja zumindest über die schnellen RAM's viel ausgleichen. Wie schon häufiger geschrieben, wird dies im professionellen Umfeld aber eher nicht erfolgen.

Das Problem beim Ryzen Start war weniger die Speicherunterstützung, für die Probleme damit war einzig und alleine AMD zuständig. Lange Zeit musste man unter Windows allerdings das Profil "Höchstleistung" auswählen um die volle Leistung des Prozessors zu bekommen. Das verschieben der Threads zwischen einzelnen CCX musste auch von Microsoft erst behandelt werden, ob die Probleme mittlerweile zu 100% behoben sind, ist mir nicht bekannt.

Man kann hier auch schlecht behaupten Microsoft würde sich speziell um Intel kümmern und AMD vernachlässigen. Wenn man sich die CPUs von Intel anschaut, merkt man schnell, dass Intel selbst es den Softwareherstellern leicht macht. Stromsparmechanismen wurden von Intel schon seit ein paar Jahren komplett in die CPU verlagert und der Aufbau der aktuellen CPUs ob mit Mesh oder Ring ist einfach gestaltet.

AMD hingegen baut ihre CPUs aus mehreren Dies zusammen. Ein Hersteller muss hier sowohl die unterschiedlichen CCX, als auch mehrere Dies berücksichtigen. Ein Threadripper WX besteht aus 64 Threads, 32 Kernen, 8 CCX, und 4 NUMA Nodes, wobei zwei davon gar keine lokalen Ressourcen besitzen. So eine "seltsame" Konfiguration gibt es weltweit nicht noch einmal.

Aber ganz generell, bleibt bei mir dieses Gefühl, wenigstens zweimal pro Jahrzent damit konfrontiert zu werden, dass der MS Kernel nur mit extra Arbeit dazu in der Lage ist, viele Kerne vernünftig zu adressieren.

Es geht nicht um die Kerne, der Scheduler von Windows verschiebt nun mal Threads von Kern zu Kern. Was auf Intel CPUs einen Sinn macht und dazu dient Hotspots zu vermeiden, ist bei AMD sehr kompliziert gelöst und muss entsprechend behandelt werden.

Wieso MS-Server hingegeben keine Probleme mit 256 Cores und X-Sockeln zu haben scheinen- bleibt dabei ein Mysterium.

Bei Serversystemen ist die Sache viel einfacher. Dort ist Numa Unterstützung seit Jahren üblich und die einzelnen Nodes werden in Gruppen angesprochen. Spricht eine Applikation nur eine bestimmte Gruppe an, bleiben die Threads auch dort.
https://docs.microsoft.com/en-us/windows/desktop/procthread/numa-support

Mit Clientsoftware ist die Sache aber problematisch. Sie verstehen nichts von Numa und würden so nur eine Gruppe nutzen. Deshalb kann man den TR auch umschalten und zwischen UMA und NUMA wechseln. So können die Applikationen zwar ohne besondere Unterstützung alle Kerne nutzen, das System muss aber selbst versuchen die Threads entsprechend aufzuteilen. Das gelingt je nach Applikation mal besser mal weniger gut.

 

[MK one]

folge des " Quad Core forever " Mottos seitens Intel auf der Consumer Plattform bis 03/2017 ...
HEDT maximal bis 10 Kerne .... , bis 03/2017 ...
ein echter Anreiz für Microsoft war ja auch nicht da um auf " High Core Count " zu optimieren bei den Home und Pro Versionen
Schon kleine Änderungen ( von Intel abweichend .. ) bei der Speicher /Kernansteuerung führen bei Microsoft oft zu Problemen , die gepatcht werden müssen , sehr, sehr oft erst Monate nach ihrem auftreten

 

[DonL_]

Komischerweise wurden alle Schwierigkeiten mit dem 1950X innerhalb von einem Jahr ausgeräumt, wie man gestern sehen konnte in allen Reviews, ist der 2950X jetzt ein absolut rundes Produkt, in jeder Software Umgebung, so kompliziert scheinen AMD CPUs nicht zu sein, wenn die Fehlerbehebung so schnell geht!

Insoweit ist dieses lamentieren, dass alles an AMD liegt, weil sie angeblich kompliziertere CPUs bauen, doch sehr weit hergeholt.
Dazu zeigt der Phoronix Test, dass Linux mit den Kernen umgehen kann, dass der 2990WX eine Nischen CPU ist, mit seiner etwas ungewöhnlichen Speicheranbindung, dürfte jedem Interessierten mehr als bewußt sein.

Wir sprechen uns mal in ein paar Jahren wieder, da ich denke das auch Intel zwangsläufig aus Kostengründen auf ein CCX Design umsteigen wird, sonst werden sie auf Dauer nicht Konkurrenzfähig sein können in der Produktion!

 

[Hill Ridge]

Wir sprechen uns mal in ein paar Jahren wieder, da ich denke das auch Intel zwangsläufig aus Kostengründen auf ein CCX Design umsteigen wird

Mit CCX Design meinst du eigentlich mehrere Dice?

 

[MK one]

haben sie doch schon angekündigt , 2 x 28 Kerne im MCM Verfahren , als verzweifelten Konterversuch gegen AMD s kommenden EPYC Rome mit 64 Kernen .

 

[Hill Ridge]

Auf das Intel-MCM bin ich echt schon gespannt.

Mich interessiert eigentlich ja nur, wie schlecht das ganze skaliert, weil intel für so ein MCM keinen passenden Interconnect hat!

 

[DonL_]

Na ja, die VEGA GPU haben sie ja auch mit einer Intellösung angebunden, ich denke die werden sich da schon etwas ausdenken, was als Interconnect funktioniert.

 

[Hill Ridge]

Na ja, die VEGA GPU haben sie ja auch mit einer Intellösung angebunden

Nicht Vega, das ist eine Polaris GPU.
Die GPU wurde einfach nur per PCIe an die APU angebunden.

ich denke die werden sich da schon etwas ausdenken, was als Interconnect funktioniert.

Das haben sie dann in einigen Jahren fertig, bringt aktuell also mal nichts!

Worse yet for Ice Lake the big Achilles Heel for their architecture, inadequate QPI bandwidth, won’t be addressed. Sure it goes up from 10.4Gbps to 11.2Gbps, but given the core count and memory speed increases, it is woefully inadequate. Sapphire Rapids brings things up a bit but won’t reach levels where AMD’s Rome will be three years earlier. AMD isn’t going to sit still mind you, but the current Naples/Epyc is already faster than Sapphire will be in that regard.

This means that even if Intel has a single core advantage, their other main strength, scaling, flips to a liability. It is bad enough that several OEM sources surveyed recently are concerned enough to scale back the lucrative multi-socket designs and look to AMD for a solution. This may seem like technical minutia but it is what an ~5 year platform delay brings to the table.

 

[MK one]

@Hill Ridge

seh ich jetzt erst , na , Namensänderung wegen den kommenden Whiskey Lake CPU s
verklag doch Intel wegen copyright Verstosses ...

 

[Hill Ridge]

Namensänderung wegen den kommenden Whiskey Lake CPU s

Nein, Namensänderung, weil ich zufällig gesehen habe, daß ich den Namen selbst ändern darf.

KA was Hill ridge wird, war ein Bonuscodename bei Semiaccurate in einem Intel-Artikel^^^

 

[xexex]

Mich interessiert eigentlich ja nur, wie schlecht das ganze skaliert, weil intel für so ein MCM keinen passenden Interconnect hat!

Intel bindet auch jetzt ihre CPUs mit UPI an, wie sowas skaliert kann man also wunderbar seit Jahren sehen. Wenn man zwei CPUs zu einem Sockel klebt, braucht man nicht extra was neues dafür entwickeln. So kann man in der Zukunft schnelle 4 Sockel Systeme mit 8 CPUs bauen, 8 Sockel Systeme sind auch heutzutage recht selten.