Test Ryzen Threadripper 2000 im Test: 32 Kerne sind verrückt, 16 sehr gut nutzbar
- Ersteller Volker
- Erstellt am
- Zum Test: Ryzen Threadripper 2000 im Test: 32 Kerne sind verrückt, 16 sehr gut nutzbar
S
Seskahin
Gast
An den Tests mit Linux und den weiteren Informationen ist ja nun bekannt, dass der Windows Scheduler hier deutlich bremst. Also diejenigen, die den großen TR brauchen, sollten eben auf Linux setzen für die Bearbeitung. Das sollte jetzt keine unüberbrückbare Hürde sein. Und die Tests sehen ja wirklich sehr gut aus.
Daneben kann man natürlich immer noch gleichzeitig Spielen, Streamen und im Hintergrund was kodieren mit dem dicken Brocken. Also für den geplanten Markt ist das von der Preis-Leistung gesehen schon eine richtige Hausnummer.
Daneben kann man natürlich immer noch gleichzeitig Spielen, Streamen und im Hintergrund was kodieren mit dem dicken Brocken. Also für den geplanten Markt ist das von der Preis-Leistung gesehen schon eine richtige Hausnummer.
Wow, einfach nur wow!
Ich bin per se kein großer AMD-Freund (bin ein gebrandmarktes Kind aus geraumen Vorzeiten ^^), aber was AMD hier zeigt, lässt einem die Kinnlade runterklappen.
Für alle Anwender von z.B. Maxon-Software im Bereich des Renderings oder generell bei Verwendung Raytraycings ist dieser Prozessor ein wahrer Segen!
Hier wäre es sehr interessant, wie viel schneller oder langsamer eine Profi-Grafikkarte im gleichen Preisbereich abschneidet, zumal ja viele Programme auch heute noch nicht in der Lage sind, sauber auf CUDA-Cores oder AMDs OpenCL zuzugreifen.
@Volker vielen Dank für diesen sehr interessanten und endlich mal wieder etwas abseits von der breiten Masse befindlichen CPU-Test
Cya, Mäxl
Ich bin per se kein großer AMD-Freund (bin ein gebrandmarktes Kind aus geraumen Vorzeiten ^^), aber was AMD hier zeigt, lässt einem die Kinnlade runterklappen.
Für alle Anwender von z.B. Maxon-Software im Bereich des Renderings oder generell bei Verwendung Raytraycings ist dieser Prozessor ein wahrer Segen!
Hier wäre es sehr interessant, wie viel schneller oder langsamer eine Profi-Grafikkarte im gleichen Preisbereich abschneidet, zumal ja viele Programme auch heute noch nicht in der Lage sind, sauber auf CUDA-Cores oder AMDs OpenCL zuzugreifen.
@Volker vielen Dank für diesen sehr interessanten und endlich mal wieder etwas abseits von der breiten Masse befindlichen CPU-Test
Cya, Mäxl
H
Hotstepper
Gast
@Krautmaster
Was ich grundsätzlich nicht verstehe ist warum du so einen fuzz darum machst, dass man entweder 99% oder 99.9% oder 99.99% machen muss. Man hat den Datensatz doch so oder so. Man kann den auch in feinsten Stufen komplett darstellen. Gehts da eventuell um Animositäten?
Du tust bist doch sonst immer pro jedem Test... warum denn hier plötzlich nicht?
Wenn in einer Szene jeder 110. Frame stottert, ist das für Dich nicht relevant? Darf man sowas nicht wissen wollen? Und wenn die Szene 3min lang ist aber eine Plattform in einer 15 Sekunden Szene heftig stottert, ist das für den Gamer plötzlich egal weil ja die Average FPS sauber sind und die 99% Frametimes ebenso?
Nochmal... die Tester haben die Daten ja sowieso. Alles was es bedarf ist einer Darstellung die solche Aussetzer auch reportet.
Was ich grundsätzlich nicht verstehe ist warum du so einen fuzz darum machst, dass man entweder 99% oder 99.9% oder 99.99% machen muss. Man hat den Datensatz doch so oder so. Man kann den auch in feinsten Stufen komplett darstellen. Gehts da eventuell um Animositäten?
Du tust bist doch sonst immer pro jedem Test... warum denn hier plötzlich nicht?
Wenn in einer Szene jeder 110. Frame stottert, ist das für Dich nicht relevant? Darf man sowas nicht wissen wollen? Und wenn die Szene 3min lang ist aber eine Plattform in einer 15 Sekunden Szene heftig stottert, ist das für den Gamer plötzlich egal weil ja die Average FPS sauber sind und die 99% Frametimes ebenso?
Nochmal... die Tester haben die Daten ja sowieso. Alles was es bedarf ist einer Darstellung die solche Aussetzer auch reportet.
Zuletzt bearbeitet von einem Moderator:
Sun_set_1
Captain
- Registriert
- Sep. 2008
- Beiträge
- 4.048
@xexex @MK one
Das ein Flaschenhals vorhanden ist, wenn die RAM Kommunikation von vier Dies über zwei gechannelt wird, ist doch vollkommen klar. Die seitenlange Diskussion darüber, finde ich, ehrlich gesagt etwas drüber.
Übertrieben gesagt, handelt es sich beim 2990 um einen LKW mit einer PKW-Kardanwelle.
Trotz dessen @xexex
Stimme Dir im Großen und Ganzen zu. Für mich bleibt aber der Punkt, dass das Verhältnis in sich beim Linux Benchmark nicht passt. Selbst wenn man, wie von Dir vorgeschlagen, die 70% weglässt (die keine intensive RAM-Kommunikation erfordern), stimmt das auch bei den restlichen 30% im Vergleich zu den Windows-Ergebnissen nicht überein.
Hier meine ich explizit das prozentuale Leistungsergebnis im Verhältnis TR 2990 / 2950 und i9.
Hier bleibt für mich einzig und alleine die Erklärung, dass der Linux-Kernel anders, besser skaliert / verteilt.
Und das Microsoft bereits zu Windows XP Zeiten sagte, dass sie ihren Kern nicht auf AMD Multi-Core optimieren werden, ist keine Verschwörungstheorie. Den damals extra von AMD veröffentlichen DualCore Optimizer, um dem XP Kernel überhaupt irgendwie unter die Arme zu greifen, bilde ich mir ja nicht ein.
Aufgrund dessen, sollten diese Unterschiede meines Erachtens nach kritischer hinterfragt werden, als das von vorne Weg komplett auf die DIE-RAM Bridge zu schieben.
Das ein Flaschenhals vorhanden ist, wenn die RAM Kommunikation von vier Dies über zwei gechannelt wird, ist doch vollkommen klar. Die seitenlange Diskussion darüber, finde ich, ehrlich gesagt etwas drüber.
Übertrieben gesagt, handelt es sich beim 2990 um einen LKW mit einer PKW-Kardanwelle.
Trotz dessen @xexex
Stimme Dir im Großen und Ganzen zu. Für mich bleibt aber der Punkt, dass das Verhältnis in sich beim Linux Benchmark nicht passt. Selbst wenn man, wie von Dir vorgeschlagen, die 70% weglässt (die keine intensive RAM-Kommunikation erfordern), stimmt das auch bei den restlichen 30% im Vergleich zu den Windows-Ergebnissen nicht überein.
Hier meine ich explizit das prozentuale Leistungsergebnis im Verhältnis TR 2990 / 2950 und i9.
Hier bleibt für mich einzig und alleine die Erklärung, dass der Linux-Kernel anders, besser skaliert / verteilt.
Und das Microsoft bereits zu Windows XP Zeiten sagte, dass sie ihren Kern nicht auf AMD Multi-Core optimieren werden, ist keine Verschwörungstheorie. Den damals extra von AMD veröffentlichen DualCore Optimizer, um dem XP Kernel überhaupt irgendwie unter die Arme zu greifen, bilde ich mir ja nicht ein.
Aufgrund dessen, sollten diese Unterschiede meines Erachtens nach kritischer hinterfragt werden, als das von vorne Weg komplett auf die DIE-RAM Bridge zu schieben.
Zuletzt bearbeitet:
Wenn man die Benchmarks von Phoronix anschaut ist die mangelhafte Skalierung von 2950 zu 2990 wohl zu 95% Windoze anzulasten - unter Linux skalieren die 32 Kerne DEUTLICH besser. Gleichzeitig wischen alle getesteten Distros mit Windoze den Boden auf 
Krautmaster
Fleet Admiral
- Registriert
- Feb. 2007
- Beiträge
- 24.312
Hotstepper schrieb:
bitte ordne mal für mich die Farben zu.
Fragger911
Rear Admiral
- Registriert
- Okt. 2006
- Beiträge
- 5.790
En3rg1eR1egel schrieb:
Oh Du Nabel der Welt: [kleine Korrektur]
- ein Produkt was DU nicht brauchst
- Software für solche Hardware gibt es seit Jahren, nur war solche Hardware vorher nicht in diesen Preisregionen verfügbar
- Leute können auf alles und jeden hereinfallen (selbst auf Intel oder gar Politiker), wenn sie sich nicht informieren... das hat nichts mit Threadripper zu tun
H
Hotstepper
Gast
Krautmaster schrieb:
Ich bin eben leider in dem Plot verrutscht und hab das in der Sekunde korregiert als du gepostet hast. Das ändert aber nichts am Rest der Punkte, zumal alleine die Häufung des Stotterns der HEDT CPUs gegenüber den anderen statistische Signifikanz hat.
Erlär doch einfach Deine Abneigung, denn es ist offensichtlich kein Würfeln was dieser Plot zeigt.
- Registriert
- Aug. 2004
- Beiträge
- 11.742
@Krautmaster @Hotstepper
Streitet Ihr Euch jetzt ernsthaft darüber ob eine transparente Darstellung von Messergebnissen sinn macht oder nicht?
Streitet Ihr Euch jetzt ernsthaft darüber ob eine transparente Darstellung von Messergebnissen sinn macht oder nicht?
Krautmaster
Fleet Admiral
- Registriert
- Feb. 2007
- Beiträge
- 24.312
Hotstepper schrieb:
klar is das relevant, und klar darf man das wissen wollen. Ich habe sogar vorgeschlagen, dass mal ausgiebiger zu untersuchen. Die 99er Werte sind gut, egal ob bei TR oder SLX. Du hast den 99,9 Werten weil sie in dein Intel SLX Beuteschema passen ne große Bedeutung in diesem THG Test zugesprochen, was ich relativierte, und auch begründete und darlegte. Außer Polemik wie "stell die Fraben" ein kommt ja nix.
Nur weil ich sag dass die 99,9 Werte bei THG wenig Aussagekraft haben (da sie schon wegen ein paar Mhz OC wahnsinnig streuen) heißt dass nicht dass es sinnvoll ist das zu untersuchen, weil selbst 99,9% Perzentile bedeuten ja Ruckler in größeren Abständen.
Scheint als hast du das überlesen:
Krautmaster schrieb:@Hotstepper
Noch ne kleine Anmerkung zu den Frametimes. klar ist ggf die Tendenz zu erkennen dass TR und SLX anfälliger auf vereinzelte, seltene Ruckler sind als Ryzen und Coffee, was aber in der Natur der Sache liegt (wenn wie gesagt auf entfernten Ram zugegriffen werden muss).
Deswegen gibts den GameMode, deswegen gibts Numa.
Wenn man das mal genauer analysieren wöllte müsste man wirklich einen laaaangen Testlauf in einem Problemtitel machen und dann auch andere Ursachen einbeziehen.
Gerade sowas wie:
und dann kann man schauen was bei rauskommt und wie man zb durch
- Windows Power Schema
- Speedstep / Cstates enable / disable
- Speedshift
- SMT Enable / disable
- selbst ein Virenscanner kann bei sowas wie diesen >99 % Latenzen reinfunken
OC, RamOC, Mesh OC, Latenzoptimierung, IF Optimierung, entgegensteuern kann.
Die Frage ist ob sich das lohnt, imho kauft sich ja keiner nen 2990Ws oder Intel 10 -18 Kern für das letzte Quentchen Frametimes.
Da kauft man sich aktuell nen Coffee oder nen hochoptimierten Ryzen 2700X. Is auch wirtschaftlicher
Sun_set_1 schrieb:
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. Während man die Geheimhaltung zum Ryzen Launch noch verstehen konnte und vielleicht deshalb auch Microsoft nicht rechtzeitig informiert hat, hätte AMD durchaus die Möglichkeit gehabt die Optimierungen vor der offiziellen Ankündigung der TR WX CPUs durchführen zu lassen. So bleibt leider der erste Eindruck für eine gewisse Zeit bestehen und schlechte Publicity ist das letzte was AMD braucht.
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.
Offensichtlich wollte Microsoft hier nicht und braucht erst den Druck der Kunden, bis sie in Wallung kommen.
.Sentinel.
Admiral
- Registriert
- Okt. 2007
- Beiträge
- 8.643
HaZweiOh schrieb:
Nö- Microsoft hat ja damals bei den Bulldozern auch wirklich schnell reagiert und einen Hotfix für den Scheduler rausgebracht, der auf den AMD Prozessor besser gepasst hat.
Was hätte Microsoft davon, dort irgendetwas zu verzögern? Die wollen Doch ihr OS an die vermeintlich neue Kundschaft loswerden...
HaZweiOh schrieb:
Es ist mir nicht bekannt wie viele Änderungen am Kernel oder am Scheduler von AMD in der letzten Zeit eingeflossen sind, dass der Linux Scheduler anders funktioniert, ist jedoch nicht erst seit heute allgemein bekannt.
EDIT: Hier mal die offiziellen Zahlen.
https://www.linuxfoundation.org/2017-linux-kernel-report-landing-page/
Wahrscheinlich ist der Patch für Microsoft schwieriger als damals. Dass AMD sich rechtzeitig um Linux kümmert, wo sie alles alleine machen müssen, aber auf der anderen Seite Windows außen vor lässt (wo Microsoft die Arbeit leisten muss) ist höchst unwahrscheinlich.
Zuletzt bearbeitet:
chithanh
Commodore
- Registriert
- Okt. 2013
- Beiträge
- 4.154
xexex schrieb:
Es ist in der Tat so, dass Microsoft oftmals kein Interesse hat, die Bugs und Unzulänglichkeiten bei der Skalierung auf viele Kerne/Threads proaktiv zu beseitigen. Erst wenn das Problem bei vielen oder bei prominenten Anwendern auftritt, handeln sie.HaZweiOh schrieb:
Die Google Chrome/Chromium-Entwickler können ein Lied davon singen. Beim Upgrade ihrer Build-Hardware auf Vielkerner sind sie immer wieder in Skalierungsprobleme unter Windows reingelaufen. Diese Probleme waren Microsoft teilweise bereits bekannt.
- Prozesse wurden nach Beendigung singlethreaded abgeräumt, halten dabei ein Lock um das mit GUI-Tasks konkurriert wird https://randomascii.wordpress.com/2017/07/09/24-core-cpu-and-i-cant-move-my-mouse/
- Wenn man viele Zombie-Prozesse hat, belegen die eine erhebliche Menge an RAM https://randomascii.wordpress.com/2018/02/11/zombie-processes-are-eating-your-memory/
- Der Windows-Loader hat einen Caching-Bug, der in Situationen mit vielen Threads manchmal Instruktionen mit lauter Nullen ausführt https://randomascii.wordpress.com/2018/02/25/compiler-bug-linker-bug-windows-kernel-bug/
