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

[Krautmaster]

was das Architektur Thema angeht hat xexex absolut recht. Nicht mal AMD macht da ein Geheimnis draus dass der TR da eine Sonderbehandlung braucht und MS wird sicher auch gewillt sein den Scheuleder hier anzupassen. Es gibt aber schon sehr viele Spezialfälle die man berücksichtigen muss.

zB.:

• ist es eine AMD Modul basierte CPU, ein Ryzen CPU / eine Multi Chip CPU oder ein Intel (ganz generell) wegen phys und virt Kerne
• Bei AMD primär die Threads in ein CCX legen sofern sie miteinander zu tun haben (kleine Core to Core Latency)
• bei Intel aufgrund der Thermik eher "entfernte Kerne" auslasten, aber auf einer Die (nicht Sockel übergreifend)
• Wann lege ich bei AMD die weiteren Threads ins gleiche CCX, oder ins andere CCX derselben die, oder auf eine andere Die und welche CCX da? -> ich will ja die Speicheranbindung schnell halten
• Wenn nun eine Die wie bei nem Ryzen 2700X voll belegt wird muss im dümmsten Fall der Speicherzugriff bei Epyc / TR über die andere Die erfolgen. Haben die Threads aber ein gemeinsames Workset wäre die Auslastung einer Die gegenüber einer verteilten Auslastung von Vorteil
• Hab ich wie beim Rendern getrennte Worksets muss ich aufgrund der Thermik und zur Maximierung der Speicherbandbreite alle Die gleichmäßig belegen, außer natürlich beim Threadripper der ja zwei schwächer angebundene Die besitzt

und so gehts grad weiter. Es ist eben nicht ganz klar und auch nicht deterministisch was nun die beste optimale Belegung ist. Da spielen soooo viele Faktoren mit rein. Der Windows Scheuleder weiß ja auch nicht ohne weiteres was der Thread zu tun hat, ob er für sich agiert oder zb wie bei FFMPEG Abhängigkeiten bestehen und der eine ggf auf Speicher des anderen zugreifen will.

Man kann schon lange nicht mehr stumpf in Virtuelle und Physikalische Kerne unterteilen und gut ist. bei Intel noch am ehesten, da es weit "homogener" zugeht. Da wirft man random die Aufgaben den physikalische kernen zuerst zu, auf einer Die. fertig. Zudem hüpfen die belasteten Kerne noch etwas durch die Gegend, vermutlich der Thermik wegen.

Edit: Man sieht ja schon an den Benchmarks dass es von Aufgabe zu Aufgabe stark abhängt. Renderen ist nicht umsonst seine Stärke, da ist es quasi vollkommen latte wie man die CPU belegt da 0 Abhängigkeiten zwischen den Atomaren Threads bestehen.
Auch die verschiedenen Modi die AMD implementiert und die sich umschalten lassen zeigen schon dass es eben nicht so trivial ist.

 

[Cool Master]

Schlechte Publicity hängt einem Produkt an, wie ein Stück Scheiße am Schuh. Wie lange hat man Ryzen eine schlechte Speicherunterstützung nachgesagt?

In der anfangs Zeit war das halt auch der Fall. Dank BIOS Updates ist das kein Thema mehr.

Der Ruf klebt bis heute an den CPUs.

Nicht wirklich. Was ich eher als Problem sehe ist das der Media Markt z.B. nur vier Rechner mit Ryzen 5 und einen mit Ryzen 3 hat.

In der derzeitigen Form, kann man von dem WX unter Windows eigentlich nur abraten, also woher soll der Umsatz kommen?

Zum Beispiel Linux User die das Teil als Server/WS einsetzen. Windows kann man immer noch in einer KVM betreiben.

 

[Deinorius]

Der Test ist wirklich nicht gelungen. Ihr habt ein Core Monster mit Spielen getestet? Obwohl jedem klar ist, das Spiele 2018 immer noch, nur von SingleCore Leistung profitieren.
Die Arbeit hättet ihr euch sparen können. Wieso testet ihr Spiele? Fehlt euch der Horizont, wie man so eine CPU einsetzen kann?

Sie haben 8 Anwendungen und 6 Spiele getestet. Es sind insgesamt nicht so viele Tests. Es dürfen mehr Anwendungsbenchmarks sein, aber grob wurde so weit gut ausgesucht.
Und natürlich testen sie auch Spiele. Das ist eine IT-Seite, wo es auch um Spiele geht, oder auch vorwiegend. Eine 32C CPU ist natürlich nicht dafür gedacht, um Spiele darauf zu spielen. Aber in diesem Fall war es hilfreich, um die Nachteile dieser CPU bezüglich 4 Dies und nur QuadChannel IMC aufzuzeigen. Die meisten Leser können hier nichts mit Server eigenen Benchmarks anfangen. Wie gesagt, mehr Rendering Benchmarks oder auch ein Office/Excel Benchmark würden das ganze besser abrunden, aber gerade bei der 16C CPU schaden die Spiele Benchmarks keineswegs.
Wer sich so eine CPU privat kauft, wird hoffentlich etwas mit diesen Cores anfangen können, aber womöglich nebenbei auch etwas spielen wollen. Es sind nur 6 Spiele, nicht 20. Ich habe es schon weiter oben angedeutet, ein eigener Benchmark, wo im Hintergrund nebenbei etwas gerendet wird und man währenddessen einen Spiele Benchmark mit hoher CPU-Last laufen lässt. Läuft das Spiel mit (deutlich) weniger fps? Wieviel Leistung geht durch das Spiel für das Rendering ab?

Linus macht hin und wieder völlig verrückte Sachen, wenn er auf einem PC mit einer Atom basierender MultiCore-CPU Spiele testen will, sich dabei vorher denkt "Das ist idiotisch, aber machen wir es dennoch.", es aber dennoch macht und zu wenig überraschenden Ergebnissen kommt, welche dennoch interessant sein können.

 

[oldmanhunting]

Nicht wirklich. Was ich eher als Problem sehe ist das der Media Markt z.B. nur vier Rechner mit Ryzen 5 und einen mit Ryzen 3 hat.

Wenn beim Mediamarkt am Tag 90% der Kunden einen Intel Rechner kaufen und 10% einen AMD Rechner, dann wirkt sich das darauf aus, was im Regal steht.
Reicht halt nicht, wenn man ein Produkt auf den Markt bringt und dann dafür keine Werbung macht.

 

[DocWindows]

installierst du für deine Intel CPU einen Treiber ?

Mein Treiber heißt intelppm.sys
Wird aber mit Windows mitgeliefert. Genauso wie AMD-Treiber.
Für ältere CPUs gabs aber auch schon separate Treiberdateien die man installieren konnte, aber nicht musste.

Es geht ja auch eher um die Mechanik dahinter, also die Möglichkeit sowas zu installieren.
Wenn eine CPU eine bestimmte Funktionsweise des Systems braucht, die das System so nicht implementiert hat, es aber über ein Kernelmodul Ttreiber) zu lösen wäre, könnte man es doch einfach machen.
Es geht ja hier nur um Optimierung und nicht um die generelle Funktion der CPU.

Nur ist für mich ein Treiber etwas , was ich selber installiere für eine Hardware, weil sie ohne dem nicht läuft .

Eine Grafikkarte "läuft" auch mit dem MS Basic Display Adapter. Um alle Funktionen nutzen zu können, installiert man aber einen extra Treiber. Hohe Auflösungen, 3D-Funktionen, Powermanagement, etc.pp.
Analog dazu könnte man einen extra CPU-Treiber installieren um eine andere, CPU-spezifische optimierte Threadverteilung zu erreichen. Vorausgesetzt die Kernel API gibt das her.

 

[Linmoum]

Beim 32-Kerner musste der Game Mode hingegen zwingend zum Einsatz kommen, um Abstürzen in Far Cry 5 oder extrem niedrigen FPS in Total War vorzubeugen. Aber auch in anderen Titeln zogen die FPS mit weniger aktiven Kernen an. Auch in den Spielen wird am Ende aber auf das Rating verzichtet, weil es das Bild zu stark verzerrt.

Oder man bencht mal mit Radeon-GPU, das gab's ja schon im Zusammenhang mit Ryzen (und DX12). Siehe Golem zum Thema Gaming und 2990WX.

Nach dem Wechsel von der Geforce auf eine Radeon RX Vega 64 (Test) stieg die Bildrate in vier der fünf geprüften Spiele drastisch, zumeist verdoppelt sie sich grob. Einzig Assassin's Creed Origins läuft auf dem Threadripper 2990WX auch mit der AMD-Karte so langsam wie zuvor. Wir haben bei Nvidia angefragt, ob das Treiber-Problem bekannt ist.

https://www.golem.de/news/32-kern-cpu-threadripper-2990wx-laeuft-mit-radeons-besser-1808-136016.html

 

[Dai6oro]

Einfach erstaunlich was man für ein "falsches" Bild (wohl eher ungenügendes Gesamtbild) man bekommen kann wenn man nicht alle OS und GPU Hersteller testet.

 

[Hill Ridge]

Da war NVIDIA wohl zu blöd den Treiber rechtzeitig auf 64T zu optimieren.

Ist ja nicht so, als ob der 32C TR2 nicht schon seit Monaten erwartet wurde...

 

[xexex]

Kannst du die Aussage erläutern?

Habe ich bereits!

However, on AMD's Ryzen 1800X, latency times are a wholly different beast. Everything is fine in the L1 and L2 caches (32 KB and 512 KB, respectively). However, when moving towards the 1800X's 16 MB L3 cache, the behavior is completely different. Up to 4 MB cache utilization, we see an expected increase in latency; however, latency goes through the roof way before the chip's 16 MB of L3 cache is completely filled. This clearly derives from AMD's Ryzen modularity, with each CCX complex (made up of 4 cores and 8 MB L3 cache, besides all the other duplicated logic) being able to access only 8 MB of L3 cache at any point in time.

The difference in access speeds between 4 MB and 8 MB workloads can be explained through AMD's own admission that Ryzen's core design incurs in different access times depending on which parts of the L3 cache are accessed by the CCX. The fact that this memory is "mostly exclusive" - which means that other information may be stored on it that's not of immediate use to the task at hand - can be responsible for some memory accesses on its own. Since the L3 cache is essentially a victim cache, meaning that it is filled with the information that isn't able to fit onto the chips' L1 or L2 cache levels, this would mean that each CCX can only access up to 8 MB of L3 cache if any given workload uses no more than 4 cores from a given CCX. However, even if we were to distribute workload in-between two different cores from each CCX, so as to be able to access the entirety of the 1800X's 16 MB cache... we'd still be somewhat constrained by the inter-CCX bandwidth achieved by AMD's Data Fabric interconnect... 22 GB/s, which is much lower than the L3 cache's 175 GB/s - and even lower than RAM bandwidth. That the Data Fabric interconnect also has to carry data from AMD's IO Hub PCIe lanes also potentially interferes with the (already meagre) available bandwidth
https://www.techpowerup.com/231268/...yzed-improvements-improveable-ccx-compromises

Im Vergleich dazu Intel Scalable

As you can see, there is not just this extra AVX-512 unit hanging off the base Skylake core, but also an additional chunk of L2 cache. For as long as we can remember, Intel has had 256 KB of L2 cache per core, but with the Skylake Xeons, this is being quadrupled to 1 MB, and it is being done by hanging 768 KB of extended L2 cache on the outside of the core. The L1 data and instruction caches on Skylake are the same at 32 KB each, but the L1 data cache has its load and store bandwidth doubled so it can do two 64 byte loads and one 64 byte store per cycle.

The L2 and L3 caches on the Skylake are organized differently, and these tweaks are only available in the server variants of the Skylake chips just like the integrated mesh architecture is also only used on the server versions. (More on that mesh in a moment.)

With prior Xeon processors, each core had its own private L2 cache that weighed in at 256 KB, and each core also had a 2.5 MB segment of L3 cache that was roughly associated with that core. With the prior Xeons, the shared L3 cache was inclusive, which meant that the L3 cache had copies of all cache lines in the L2 caches. But with the Skylake Xeons, Intel has shifted to a non-inclusive L3 cache structure, which means that the L2 cache lines may not be in the share L3 cache. The other big change is from a shared, distributed L3 cache that was created from those segments to a private, local L2 cache that is tightly coupled to each core and that uses the shared L3 cache more like an overflow cache. The L3 cache for the Skylake Xeons is considerably smaller, at 1.375 MB per core, but the L2 cache is bigger and compensates for this. The overall effect, says Kumar, is that the caches can better feed the cores, and this is particularly important for virtualized and multithreaded workloads, which were spending a lot of time going out to L3 cache and hitting the uncore regions of the chip. The downside is that the L2 cache latency has increased by two cycles, but the larger L2 cache more than masks this latency.
https://www.nextplatform.com/2017/08/04/drilling-xeon-skylake-architecture/

Vereinfacht ausgedrückt, hat Intel knapp den doppelten L1 und L2 Cache und oben drauf einen großen geteilten L3 Cache auf den alle Kerne mit einer halbwegs ähnlichen Geschwindigkeit über das Mesh zugreifen können.

Bei AMD hat man schon mal mehrere Dies, die nicht auf den Cache eines anderen Dies zugreifen können, aber auch die Aufteilung auf einem Die ist bei weitem nicht so einfach gestaltet.

Jede Umschaltung von einem Kern auf einen anderen muss bei AMD anders bewertet werden, bei Intel geht dabei hingegen nur der Inhalt vom L1 und L2 Cache verloren, welcher vom geteilten L3 Cache wieder ohne einen Zugriff auf den langsamen RAM aufgefüllt werden kann.

Hier auch noch ein einfacher Vergleich der Architekturen.
https://www.tomshardware.com/news/intel-mesh-architecture-skylake-x-hedt,34806.html

 

[werpu]

Der geteilte Intel Cache ist eine der Hauptursachen von Meltdown.

 

[Ned Flanders]

@xexex

Es ist halt sehr schwer zu bestimmen wie groß der L3 Cache effektiv ist ohne zu wissen was Intel mit "non-inklusive" meint. Außer bei Skylake-SP ist es ja sowieso ein inklusiver Cache und damit effektiv kleiner je Kern (beim 8700k (12-1.5)/6=1.75mb/Kern) gegen (2x8/8=2mb/Kern beim 2700x bzw noch mehr beim 2600x)). Er scheint ja zumindest nicht exclusive zu sein, denn so hätte man das traditionell genannt.

Auch ist mir noch immer nicht klar warum ein Kern von CCX0 im Victim Cache von CCX1 nach Daten suchen soll. Das macht aus meiner Sicht nur bei inklusiven Architekturen Sinn. Aber vieleicht hast du da eine Antwort drauf.

Es ist wohl mit wie so vielem bei den neuen CPUs beider Hersteller. Es lässt sich nicht gerade einfach bewerten weil uns schlicht viel zu viele Informationen fehlen. Ich hab bei meinem Ryzen mit Process Lasso auch mal aktiv Anwendungsthreads getrennt auf das jeweils andere CCX. Der Performance hit war aber praktisch zu vernachlässigen <3%. Daher stehe ich diesen Argumenten etwas skeptisch gegenüber. Das sieht auf dem Papier schlüssig aus, ist es am Ende aber dann doch nicht wirklich.

 

[MK one]

Der geteilte Intel Cache ist eine der Hauptursachen von Meltdown.

Nicht nur für Meltdown , sondern noch für eine Reihe anderer " Intel only " spezifischer Sicherheitslücken , die Intel im Datacenter Bereich ne Menge Kunden kosten wird , meiner Meinung nach ...

 

[Volker]

Oder man bencht mal mit Radeon-GPU, das gab's ja schon im Zusammenhang mit Ryzen (und DX12). Siehe Golem zum Thema Gaming und 2990WX.


"Nach dem Wechsel von der Geforce auf eine Radeon RX Vega 64 (Test) stieg die Bildrate in vier der fünf geprüften Spiele drastisch, zumeist verdoppelt sie sich grob. Einzig Assassin's Creed Origins läuft auf dem Threadripper 2990WX auch mit der AMD-Karte so langsam wie zuvor. Wir haben bei Nvidia angefragt, ob das Treiber-Problem bekannt ist. "

Einfach erstaunlich was man für ein "falsches" Bild (wohl eher ungenügendes Gesamtbild) man bekommen kann wenn man nicht alle OS und GPU Hersteller testet.

Nunja, ganz so ist es nicht. Da widersprechen die Diagramme auch klar den Worten bei Marc. 2 Spiele gehen krass ab, von 5. In Kingdom Come ist ihre GF-wert auch extrem schlecht, sah bei uns entspannt aus.

Habs mal bei uns kurz gegengetestet. Unterschied: Golem testet zudem nur in 720p, wir machen 1080p.

Kingdom Come habe ich auch einen Unterschied, von 41,7 auf 45,6 FPS (1080 Ti zu Vega 64)
Project Cars 2 von 52,3 auf 58,1
Warhammer von 9,9 auf 10,1 ^^

Also ja, Vega kann was besser machen. Aber nicht den heiligen Gral finden.

 

[MK one]

na ja ... , bedenkt man das sich Vega64 normalerweise nicht auf 1080 TI sondern eher 1080 Niveau oder leicht darüber befindet .. , in Prozenten hört es sich besser an als in FPS Project Cars 2 dann 10-11 % schneller als 1080 TI Kingdom Come 8 - 9 %, während Warhammer gleich ist .

 

[xexex]

Es ist halt sehr schwer zu bestimmen wie groß der L3 Cache effektiv ist ohne zu wissen was Intel mit "non-inklusive" meint.

Liest du was ich schreibe? Es ist ganz klar was non inclusive heißt.

Intel has shifted to a non-inclusive L3 cache structure, which means that the L2 cache lines may not be in the share L3 Cache.

Das wurde eben in Mesh CPUs geändert um die CPUs besser an aktuelle Workloads anzupassen.

Auch ist mir noch immer nicht klar warum ein Kern von CCX0 im Victim Cache von CCX1 nach Daten suchen soll. Das macht aus meiner Sicht nur bei inklusiven Architekturen Sinn. Aber vieleicht hast du da eine Antwort drauf.

A victim cache is a hardware cache designed to decrease conflict misses and improve hit latency for direct-mapped caches. It is employed at the refill path of a Level 1 cache, such that any cache-line which gets evicted from the cache is cached in the victim cache. Thus, the victim cache gets populated only when data is thrown out of Level 1 cache. In case of a miss in Level 1, victim cache is looked up. If the resulting access is a hit, the contents of the Level 1 cache-line and the matching victim cache line are swapped.
https://en.wikipedia.org/wiki/Victim_cache

Ein Prozess wird auf einem Kern ausgeführt, und die Daten befinden sich im L1 oder L2 Cache. Bei einem Taskswitch werden diese Daten aus diesen Caches rausgeworfen und landen im L3 Cache. Der nächste Kern holt sich die Daten dann in seinen L2 und L1 Cache und arbeitet damit weiter.

Bei AMD klappt das nur, wenn der Switch innerhalb eines CCX passiert, ansonsten müssen die Daten aus dem Speicher geholt werden, dabei stehen einem Die beim TR WX nur 2 oder gar keine direkt angeschlossenen Speicherkanäle zur Verfügung.

 

[MK one]

Wenn man eine Exoten CPU bastelt und die dann weil die ein Exot ist nicht vernünftig mit Windows zusammenarbeitet, dann darf man sich doch später nicht darüber beschweren.
Kann mir doch keiner erzählen, dass AMD solche Sachen nicht schon beim Design der CPU gewußt hat. Neee, wird trotzdem so gebaut und gebracht.

es wird dich Wundern ...( mich nicht ) , das es einen Unterschied macht ob ein OS Open Source ist , oder nicht ...
Linux ist open source , jeder Programmierer kann machschauen wie was funktioniert .
Microsoft ist nicht " open source "

übrigens ... bei der neuen Sicherheitslücke Marke " Intel only " Foreshadow / L1TF ist Linux auch schneller als Windows https://www.heise.de/security/meldu...-Prozessorluecke-Foreshadow-L1TF-4137264.html
betrifft zwar nicht den Heimanwender jedoch
Cloud-Anbieter und Admins von Systemen, bei denen Nutzer in virtuellen Maschinen eigene Betriebssysteme oder Kernel einspielen können, müssen für den Schutz nicht nur die Updates einspielen, sondern auch HyperThreading (HT) deaktivieren. Beim Betrieb von VMs können die Gegenmaßnahmen zu einem Performance-Verlust von bis zu fünfzig Prozent führen, heißt es in Linux-Kreisen

LOL

 

[y33H@]

Da widersprechen die Diagramme auch klar den Worten bei Marc.

Hab das Fazit schon angepasst ^^

In Kingdom Come ist ihre GF-wert auch extrem schlecht, sah bei uns entspannt aus.

Ja, das Rattay Savegame produziert sehr niedrige Fps weil große Stadt.

Also ja, Vega kann was besser machen. Aber nicht den heiligen Gral finden.

Ebend ... zumal längst nicht alle Spiele auf dem 2990WX und ner Geforce so massiv einbrechen.

 

[Pokerfail]

...

Das widerspricht aber der Tatsache, dass die Benchmarks unter Linux in vielen Fällen wesentlich besser ausfallen und am Linux Kernel gab es auch keine Anpassungen speziell für ThreadRipper. Außerdem sollten die NUMA Distanzen zwischen den Dies ausreichen, um das Problem mit einem generischen Scheduler zu lösen. Oder was lässt sich damit nicht abbilden (mal abgesehen von der Kommunikation zwischen CCX)?

 

[Hill Ridge]

An Early Look At The L1 Terminal Fault "L1TF" Performance Impact On Virtual Machines

 

[Ned Flanders]

Liest du was ich schreibe? Es ist ganz klar was non inclusive heißt.

Intel has shifted to a non-inclusive L3 cache structure, which means that the L2 cache lines may not be in the share L3 Cache

Übersetz das mal, ich hab Dir die relevante Stelle sogar extra angestrichen. non-inclusive ≠ exclusive

Ein Prozess wird auf einem Kern ausgeführt, und die Daten befinden sich im L1 oder L2 Cache. Bei einem Taskswitch werden diese Daten aus diesen Caches rausgeworfen und landen im L3 Cache. Der nächste Kern holt sich die Daten dann in seinen L2 und L1 Cache und arbeitet damit weiter. Bei AMD klappt das nur, wenn der Switch innerhalb eines CCX passiert, ansonsten müssen die Daten aus dem Speicher geholt werden.

Warum sollte ein Kern sich die evicted Data eines anderen Kerns holen außer der Prozess wird vom Scheduler weitergereicht. Und warum hat das keinen dramatischen Performance impact wenn die Architektur ständig Cachemisses hat? Da gabs ja jedemenge Messungen die alle zu den gleichen Ergebnissen wie ich gekommen sind. Ob 4+0 oder 2+2 ist performanceseitig praktisch vollkommen egal.

Ich les hier immer wieder das abhängige Prozesse möglichst auf ein CCX gepackt werden müssen bei AMDs Ryzen Architektur. Zeigt doch mal real world Anwendungen die das belegen. Selbst bei Games isses völlig schnuppe.

YouTube

An dieser Stelle steht ein externer Inhalt von YouTube, der den Forumbeitrag ergänzt. Er kann mit einem Klick geladen und auch wieder ausgeblendet werden.

YouTube-Embeds laden

Ich bin damit einverstanden, dass YouTube-Embeds geladen werden. Dabei können personen­bezogene Daten an YouTube übermittelt werden. Mehr dazu in der Datenschutzerklärung.

YouTube-Embeds laden

Datenschutzerklärung