News Threadripper 3990X: 64 Zen-2-Kerne in einer TRX40-CPU kosten 3.990 USD

Krautmaster schrieb:
Das ist wirklich sehr interessant und bestätigt auch meine Benchmarks.

Schaut man sich zb den 24C AMD Ryzen Threadripper 3960X gegen meinen i9 an dann sieht es so aus:

Code:
x265 Multithread
-------------------------------------
encoded 250 frames in 5.77s (43.36 fps), 23221.11 kb/s, Avg QP:25.44
encoded 250 frames in 5.83s (42.88 fps), 23221.11 kb/s, Avg QP:25.44


System Details
--------------
    Specification        AMD Ryzen Threadripper 3960X 24-Core Processor
    Specification        DDR4-3200
    Specification        DDR4-3200
    Specification        DDR4-3200
    Specification        DDR4-3200

mein i9 7980 XE @ 4.1 Ghz @ 3000 Mesh @ 3800 Ram (wobei das kein Einfluss hat)

Code:
x265 Multithread
-------------------------------------
encoded 250 frames in 5.64s (44.29 fps), 23221.11 kb/s, Avg QP:25.44
encoded 250 frames in 5.67s (44.13 fps), 23221.11 kb/s, Avg QP:25.44


System Details
--------------
Specification Intel(R) Core(TM) i9-7980XE CPU @ 2.60GHz
Specification DDR4-3200

Wobei das Testset mit nur 6s Laufzeit etwas kurz ist. Und wenn kauft man sich ja wohl nen richten Threadripper, kein so ein 24C Lümmel.
Fairerweise müsstest du den kompletten Bericht posten! ;)
Und mich hast du ganz vergessen... :(

Daher mach ich das mal... :D
https://docs.google.com/spreadsheets/d/1z9OMFSLGyCKeFG0Q6jzIbp-RRL5OpjJ_WLUzFUpuo7g/htmlview
 
Was soll dieser Benchmark denn eigentlich aussagen? Dass Intel da schneller ist, weil sie AVX512 in der Hardware haben?
 
HerrRossi schrieb:
Was soll dieser Benchmark denn eigentlich aussagen? Dass Intel da schneller ist, weil sie AVX512 in der Hardware haben?
Lass ihn halt.
ist halt eins der wenigen Programme die AVX512 unterstützen.
 
Ihr habt FullHD Encoding getestet.
Bin kein Profi aber Googlesuche hat das hier gebracht.

According to my tests single x265 (using default encoding settings) can saturate only 12 threads while encoding 1920x1080 footage. 3840x2160 should be enough to saturate 24 threads.
https://www.google.com/url?sa=t&source=web&rct=j&url=http://forum.doom9.org/showthread.php?t=175132&ved=2ahUKEwj03bWEu_LmAhXPyqQKHWKPAhwQFjABegQIDRAH&usg=AOvVaw0HQWn9kVUewBwU7UVJCWYF


D.h. euer Test scheint ungeeignet zu sein um CPUs mit vielen Kernen zu testen. Ausserdem ist die Testdauer von 5s zu kurz (denkt bei einem Performancetest an Warmup / Teardownzeit, welche das Ergebnis verzerren können). Ist zwar toll wenn Intel AVX512 Takt für 5 Sek. halten kann. Kann er das auch für 5 Minuten?
 
  • Gefällt mir
Reaktionen: ghecko und max9123
Snoopy69 schrieb:
Kommt auf die Anwendung an...
Hier mag allcore-OC keinen Sinn machen. Bei CB20 bringt es schon was.
Ja das stimmt schon, bei CB20 sieht man es. Nur interessieren mich halt Benchmark-Rekorde nicht, ich benche hauptsächlich um der Vergleichbarkeit willen, also um rauszufinden ob mein System so performt wie es sollte. Von daher ist der Alltagsnutzen für mich von primärem Interesse. Aber mit CCX OC werde mich mich nochmal beschäftigen irgendwann, einfach weil es mich interessiert.

Wadenbeisser schrieb:
Ich gehe mal davon aus das SMT an war, das würde dann bei dem 24 Kerner bedeuten das rein rechnerisch bei ca. 38 Kernen/Threads Feierabend war.

Habe SMT mal abgeschaltet und nochhmal getestet, die Auslastung ist aber nicht besser geworden, gefühlt eher schlechter. Hier sind die Vergleichswerte, da sieht man gut das SMT schon gut skaliert, die Zeit hat sich ohhne SMT praktisch verdoppelt:

Auto-OC (24C/48T):
encoded 1497 frames in 167.77s (8.92 fps), 20051.42 kb/s, Avg QP:22.89
Time elapsed: 00:02:48

Auto-OC (24C/24T):
encoded 1497 frames in 323.42s (4.63 fps), 20051.42 kb/s, Avg QP:22.89
Time elapsed: 0:05:24
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: yummycandy
MADman_One schrieb:
Habe SMT mal abgeschaltet und nochhmal getestet, die Auslastung ist aber nicht besser geworden, gefühlt eher schlechter. Hier sind die Vergleichswerte, da sieht man gut das SMT schon gut skaliert, die Zeit hat sich ohhne SMT praktisch verdoppelt:

Auto-OC (24C/48T):
encoded 1497 frames in 167.77s (8.92 fps), 20051.42 kb/s, Avg QP:22.89
Time elapsed: 00:02:48

Auto-OC (24C/24T):
encoded 1497 frames in 323.42s (4.63 fps), 20051.42 kb/s, Avg QP:22.89
Time elapsed: 0:05:24
Da sieht man mal, wie unterschiedlich SMT performen kann...
Bei CB15/20 hat man ohne SMT glaube noch 75% der Gesamtleistung
 
Ich halte die Massenkernhaltung auf so beengten Raum nicht für artgerecht!

;)

Das ist ein starkes Teil. Wer es gebrauchen kann soll es sich holen. Ich selber zweifle aber an den tatsächlichen Nutzen. Ich kenne mich fast gar nicht mit den Workstation/Desktop/Server Verhältnis aus. So wie ich das aber gelesen habe hier auf CB macht diese CPU nur für ausgewählte Szenarien Sinn.

Ich glaube ich habe hier mal gelesen das sich einige im Biologie Studium freuen auf die CPU wegen der Berechnung. Hatte aber selber mal Folding@home betrieben und da war doch die GPU wichtiger.
Oder hängt das doch eher von der Art der Berechnung ab?

Na egal, wer sich das Ding holt ( nicht der User) den möge gesagt sein: " Haben ist besser als brauchen "
Auch wenn es nicht artgerecht ist!
 
MADman_One schrieb:
sieht man gut das SMT schon gut skaliert, die Zeit hat sich ohhne SMT praktisch verdoppelt:
Das ist extrem ungewöhnlich und es würde mich echt interessieren wie dies zustande kommt. Denn SMT funktioniert ja so, dass die Rechenwerke des Kernes durch die beiden virtuellen Kerne besser ausgelastet werden können. Wenn also ein Thread auf etwas warten muss, dann kann der andere einspringen und die Rechenwerke nutzen, damit diese während der Wartezeit nicht ungenutzt bleiben. Natürlich sorgt der Task Scheduler des OS dafür, dass der andere Thread auch mal dran kommt, wenn es dies nicht sowieso wegen Wartezeiten nötig wird, sonst würde der ja stehenbleiben. Gibt es gar keine Wartezeiten, so bringt SMT natürlich gar nichts, da dann auch ein Thread alleine die Rechenwerke voll auslasten könnte.

Wenn also die Leistung mit SMT etwa doppelt so hoch ist, muss der eine Thread ja mindestens so 50% der Zeit warten, so dass der andere Thread des Kerns während dieser Wartezeit die Recheneinheiten nutzen kann. Nur worauf wartet der Thread? Meist sind dies RAM Zugriffe, aber wenn die RAM Bandbreite ein Flaschenhals wäre, dann müsste der zweite Thread ebenso auf seine RAM Zugriffe warten und SMT würde wieder keine Mehrleistung bringen können.
karl_laschnikow schrieb:
Ich halte die Massenkernhaltung auf so beengten Raum nicht für artgerecht!
Genau, lass und den CPU Kern Schutzverein gründen! Massenkernhaltung und dazu noch eingesperrt unter dem HS, sowas kann man nicht akzeptieren.
 
Ihr irrt euch beide...
Dank der Chiplets hat AMD doch eher "freilaufende" Cores :D


yurij schrieb:
Ihr habt FullHD Encoding getestet.
Bin kein Profi aber Googlesuche hat das hier gebracht.

According to my tests single x265 (using default encoding settings) can saturate only 12 threads while encoding 1920x1080 footage. 3840x2160 should be enough to saturate 24 threads.
https://www.google.com/url?sa=t&source=web&rct=j&url=http://forum.doom9.org/showthread.php?t=175132&ved=2ahUKEwj03bWEu_LmAhXPyqQKHWKPAhwQFjABegQIDRAH&usg=AOvVaw0HQWn9kVUewBwU7UVJCWYF


D.h. euer Test scheint ungeeignet zu sein um CPUs mit vielen Kernen zu testen. Ausserdem ist die Testdauer von 5s zu kurz (denkt bei einem Performancetest an Warmup / Teardownzeit, welche das Ergebnis verzerren können). Ist zwar toll wenn Intel AVX512 Takt für 5 Sek. halten kann. Kann er das auch für 5 Minuten?
Wahrscheinlich nicht...
Mit OC bis 4,8GHz hatte er bei einigen Kernen über 100°C (bis zu 106°C) - trotz Wasserkühlung

Eine Minute Multithread fände ich auch gut und ausreichend. Noch besser wäre, wenn der Bench alle Kerne nicht unter 100% lässt. Das ist leider mit dem Bench von jmd aus CB auch nicht möglich.

Der hier kann das, dauert aber sehr lange (mit potenter CPU min. 1h) https://www.xin.at/x265/
Hab ich zum ersten Mal bei dem lustigen Youtuber "rawiioli" gesehen
 
Zuletzt bearbeitet:
Wadenbeisser schrieb:
@Krautmaster
Habt ihr dabei auch mal auf die CPU Auslastung geachtet?
Bereits bei den Tests des 2990WX fiel auf das gerade Video Encoder ein ziemliches Problem mit den vielen Kernen/Threads hatten. Ich glaube bei x264 war z.B. nach ca. 10 Kernen Feierabend und man musste schon mehrere Videos parallel encoden um das Teil auszulasten..
Wäre komisch wenn das von CPU zu CPU so unterschiedlich wäre. Zumindest 36T sind bei x265 bei mir kein Problem voll auszulasten... bei 4K
MADman_One schrieb:
Da danach gefragt wurde, hier sind die Werte mit Deinem Benchmark von meinem TR 3960X

4.4 GHz AllCore
encoded 1497 frames in 162.66s (9.20 fps), 20051.42 kb/s, Avg QP:22.89
Time elapsed: 00:02:43

Was mir auch wieder zeigt, das das Auto-OC von AMD ziemlich gut ist und AllCore OC nur wenig Sinn macht, selbst für MT Anmwendungen.
Allerdings hatte ich bei keinem Durchlauf eine volle Kernauslastung, pendelte so um die 80%.
Top danke :)

Skaliert aber gut angesichts der 4 Min die ein 18C SLX und 16C Ryzen 3950X brauchen.
Ergänzung ()

Snoopy69 schrieb:
Der hier kann das, dauert aber sehr lange (mit potenter CPU min. 1h) https://www.xin.at/x265/
Hab ich zum ersten Mal bei dem lustigen Youtuber "rawiioli" gesehen

ja lief bei mir vorher mal durch mit
################################################################################
# ERGEBNIS: #
################################################################################

TimeThis : Elapsed Time : 01:52:15.220
 
Zuletzt bearbeitet:
Holt schrieb:
Denn SMT funktioniert ja so, dass die Rechenwerke des Kernes durch die beiden virtuellen Kerne besser ausgelastet werden können. [...] Gibt es gar keine Wartezeiten, so bringt SMT natürlich gar nichts, da dann auch ein Thread alleine die Rechenwerke voll auslasten könnte.

Umd noch mehr Quatsch von Holt zu korrigieren: Das ist so nicht korrekt.
Ein CPU-Kern besteht (fast) immer aus mehreren verschiedenen Recheneinheiten - primär sind das ALU und AGU.
(Wer deep-shit will: https://en.wikichip.org/wiki/amd/microarchitectures/zen)
In Kurzform:
https://en.wikichip.org/w/images/th..._overview.png/600px-amd_zen_hc28_overview.png
Via SMT ist es z.B. auch möglich die FPU des gleichen Kerns zu beschäftigen, während ein anderer Thread mit der ALU (Integer) beschäftigt ist. Damit ist z.B. eine deutliche Leistungssteigerung möglich - wenn die Arbeitslast darauf optimiert ist.
Andererseits verbringen Threads ständig Zeit damit, Daten aus irgendwelchen Caches zu holen - und das dauert. Lücken entstehen also bei den meisten Arbeitslasten permanent - nur sieht man sie (im Taskmanager) nicht.
 
Kann man sagen, dass SMT in Teillast mehr bringt, als Vollauslastung (kein Core nie unter 100%)
Während bei dem einen Bench weiter oben SMT wird die Zeit halbiert (bei dem Bench sind die Cores nie ausgelastet)

Schaltet man dagegen für CB15/20 SMT komplett ab, hat man nicht den halben Score - eher 75-80% davon
 
Krautmaster schrieb:
Wäre komisch wenn das von CPU zu CPU so unterschiedlich wäre. Zumindest 36T sind bei x265 bei mir kein Problem voll auszulasten... bei 4K
Das ist leider ein Punkt beim Benchen auf den man heutzutage deutlich achten muss.
Im damaligen 2990WX Artikel bei planet3dnow wurde das mal unter die Lupe genommen.
https://www.planet3dnow.de/cms/41197-amd-ryzen-threadripper-2990wx-im-planet-3dnow-review/21/
Ergänzung ()

@Snoopy69
SMT ist nur ein Lückenfüller für schlecht ausgelastete Recheneinheiten.
Je ineffizienter der Code den Kern nutzt desto mehr bleibt für weitere Threads übrig.
Das ist auch der Grund warum die Skalierung irgendwo zwischen 0 und 100% liegen oder oder wegen dem zusätzlichen Verwaltungsaufwand gar leicht ins negative gehen kann.
 
Zuletzt bearbeitet von einem Moderator:
Spannend zu lesen. Besonders der Punkt zu Workstations und Validierung.

Die Mühlen mahlen Anscheinend langsam im Businessbereich :D

Mir drängt sich halt auch die Frage auf ob AMD ab Milan (oder Genoa) auch mehr als Zwei Sockel verbauen können wird im Server.

Threadripper bleibt Single Sockel und schon hat man auch in Zukunft eine super Abgrenzung neben dem RAM Ausbau. Allerdings sehe ich auch kein Problem wenn Threadripper in Zukunft auch mit RDIMM umgehen kann.. Wer 16 Module und oder LRDIMM möchte kann ja dann immernoch zu epyc greifen bzw wenn man die Bandbreite von 8 Kanälen braucht.
 
  • Gefällt mir
Reaktionen: Sester
PS828 schrieb:
Mir drängt sich halt auch die Frage auf ob AMD ab Milan (oder Genoa) auch mehr als Zwei Sockel verbauen können wird im Server.
Sie könnten das schon lange, nur rentiert sich das nicht. Ein 2P Rome ersetzt derzeit bis zu 4 Xeons. Der Marktanteil für >2P Systeme beträgt wohl weniger als 10% und AMD hat es zuerst auf die Cloudprovider und Webhoster abgesehen, weil man über die leichter in den Markt kommt.
Ergänzung ()

STH hat das gut formuliert:

AMD EPYC 7002 v. Intel Xeon Market Impact

This is the big one. In our benchmarks, we have shown that AMD EPYC 7002 has more memory capacity (on standard SKUs), more general-purpose integer and floating-point performance, and more memory bandwidth per socket. We also showed that at a platform level, the AMD EPYC 7002 series has PCIe Gen4 and more PCIe lanes making it a more scalable solution than the Intel Xeon Scalable processors.
...
The other impact here is that AMD’s execution is strong. Delivering 2x more cores, 2x the cache, more memory bandwidth, and 2x more PCIe bandwidth in the same socket on a 2-year cadence is excellent for the x86 market.

If you are installing a new VMware ESXi cluster, you can get an AMD EPYC 7002 series CPU, like an AMD EPYC 7702P, and consolidate legacy servers at no worse than 2:1 ratios but in some cases 6:1 socket consolidation ratios even over early 2017 generation parts.

https://www.servethehome.com/amd-epyc-7002-series-rome-delivers-a-knockout/10/
 
  • Gefällt mir
Reaktionen: Sester, fuyuhasugu und PS828
Das ist natürlich ein Grund. Mal sehen wann sie auch in diesen Bereich vordringen. Priorität haben erstmal andere Dinge. Beispielsweise zertifizierung.
 
Zertifizierung ist auch nicht so leicht, wie Robert H. beschreibt:

"That's a slow crank to turn," Hallock remarked, citing that the workstation market handles much like server markets that prize staying power (like proven execution on roadmaps) and have much longer refresh cycles. AMD is still a relative newcomer to this space, and expense validation cycles are also a critical factor: In many cases, validation costs can rival the cost of procuring new hardware. Cascade Lake-X has the benefit of backwards compatibility with systems that have already been through the validation process, which also equates to more staying power in that market segment. "
Ergänzung ()

Und dann war da noch das. Finde ich eigentlich mutig, daß das jemand mal so aufschreibt:
If AMD EPYC 7002, with a massive core count, memory bandwidth, PCIe generation and lane count, power consumption, and pricing advantage cannot take significant share, we are basically done. If AMD does not gain enormous share with this much of a lead, and easy compatibility, Intel officially has a monopoly on the market and companies like Ampere and Marvell should shut down their Arm projects. If AMD does not gain significant share, there is no merit to having a wholistically better product than Intel.
 
  • Gefällt mir
Reaktionen: Sester
Das letzte ist eigentlich echt traurig.. Wenn auch Ehrlich. Ich hoffe dass es niemals so weit kommt. Wenn es einer schaffen kann dann AMD.

Too big to fail scheint es in manchen Branchen wirklich zu geben. Besonders wenn sich in den Köpfen der Entscheider nichts ändert. Denn was brauchen die denn noch als Bestätigung? Was muss amd noch tun damit die gesehen werden? Wie viel mal schneller wird man sein müssen? Das ist echt übel wenn man drüber nachdenkt
 
  • Gefällt mir
Reaktionen: yummycandy
Zurück
Oben