AMD Epyc Rome: Benchmark-Einträge listen 64-Kerner mit bis zu 2,2 GHz

AW: AMD Epyc Rome: Benchmark-Einträge listen 64-Kerner mit bis zu 2,2 GHz

ah interessant 50 000 Kerne.Ist da schon HT/SMT mit eingeflossen.Ist interessant das diese software soviele Kerne auch was anfangen kann.Das ist ja echt der fette Wahnsinn.

MPI,OpenMP und Fortran.Das letzte sagt mir etwas.Aber ich weis echt nicht was diese ganzen Programme so alles machen können.
 
AW: AMD Epyc Rome: Benchmark-Einträge listen 64-Kerner mit bis zu 2,2 GHz

AMD hat doch gar keine 64 Kerne aktuell.

Das tut doch auch gar nichts zur Sache, da wir beim Design sowieso getrennte 8C Chiplets haben, die über den IF mit einem I/O Die verbunden sind. Ob es nun also 16C oder 64C sind, macht für die TDP und die Größe der gesamten CPU einen Unterschied, aber nicht für den Takt, den so ein 8C Chiplet erreichen kann.
Ausgehend vom Leak des Ryzen 9 3850X mit 135W TDP, könnte man in der Theorie auch einen 64C Rome mit 4,2-5,1GHZ und 500W TDP machen, der wäre nur weder zu versorgen noch zu kühlen.

Und ich wiederhole es gerne nochmal: 7nm bedeutet 0,5x Verbrauch bei gleicher Leistung(Takt+Kernzahl), ein 32C Naples mit 180W TDP wird also zu einem 64C Rome mit 180W TDP bei gleichem Takt.
Würde Rome nur mit 1,4-2,2GHz arbeiten, hätten wir hier maximal 120W TDP
 
AW: AMD Epyc Rome: Benchmark-Einträge listen 64-Kerner mit bis zu 2,2 GHz

In virtuellen Umgebungen ist es doch heutzutage immer gang und gebe die Prozessoren zu überbuchen. Die Admins müssen dann verdammt aufpassen wenn solche Hosts auch produktiv werden müssen. Ein Verhältnis von 4:1 oder 8:1 ist da nichts besonderes.
 
AW: AMD Epyc Rome: Benchmark-Einträge listen 64-Kerner mit bis zu 2,2 GHz


1.) Code ist komplett vektorisiert. -> i.e. die Floating Point Units des Prozessors sind bereits voll genutzt.
2.) HT vergroessert den Task Pool der die Memory-Hierarchie belastet. Da der Code memory-bound ist und bereits daraufgehend optimisiert ist kann hier HT keine zusaetzliche Leistung beisteuern.
3.) Der Code ist fernerhin Cache-sensitiv, da HT den L3 Cache halbiert muessen die Daten aus dem main Memory gefetcht werden, was die Zugriffszeiten in die Hoehe schraubt.
 
Zuletzt bearbeitet:
AW: AMD Epyc Rome: Benchmark-Einträge listen 64-Kerner mit bis zu 2,2 GHz

interessant,noch ein workflow bzw anwendungsfall wo HT/SMT nichts bringt.Dann bin ich ja beruhigt das das nicht das einzige ist wo ich nicht nutzen kann.Und auch nicht alleine mit dem Problem bin.
 
AW: AMD Epyc Rome: Benchmark-Einträge listen 64-Kerner mit bis zu 2,2 GHz

Und du meinst ich lese mir jetzt deinen 1mio Post Bingo... durch?

Was mischst du dich überhaupt ein wenn du die Diskussion eh nicht verfolgst?:schief:
Spielst mal wieder Bullshitbingo, das steht übrigens sogar in dem Beitrag drinnen, den du zitiert hast.

"Wennd das QS Sample mit 1,4GHz Basis und 2,2GHz Turbo mit 64 Kernen mit einer wesentlichen Senkung der TDP einhergeht,"

Und wieder schön die Leute in mehreren Blogs gleichzeitig provozieren!

Man kann eine verschissene Radeon VII halt nicht wirklich besser takten als eine verschissene 2080.
Kann man halt nun nicht ändern. Nur weil ein paar unverbesserliche Sympathisanten das nicht einsehen wollen, und meinen die Radeon VII wäre mit OC schneller als eine 2080 OC und sich dann den Kirschenpflücker geben, ändert das auch nichts an der Realität.
 
AW: AMD Epyc Rome: Benchmark-Einträge listen 64-Kerner mit bis zu 2,2 GHz

1.) Code ist komplett vektorisiert. -> i.e. die Floating Point Units des Prozessors sind bereits voll genutzt.
2.) HT vergroessert den Task Pool der die Memory-Hierarchie belastet. Da der Code memory-bound ist und bereits daraufgehend optimisiert ist kann hier HT keine zusaetzliche Leistung beisteuern.
3.) Der Code ist fernerhin Cache-sensitiv, da HT den L3 Cache halbiert muessen die Daten aus dem main Memory gefetcht werden, was die Zugriffszeiten in die Hoehe schraubt.

Welche Anwendungen sind das genau? Davon höre zum ersten Mal im meinem Leben.
Wenn der Code cache-sensitiv ist, müsste ein Prozessor mit größeren Caches genau das Skalierungsproblem mit HT oder SMT aufheben.
Die Bedingungen damit SMT oder HT nicht skalieren müssen sehr viele Bedingungen erfüllt sein.
Deine Anwendung müsste Cache Misses permanent verhindern und selten bzw gar nicht auf den Arbeitsspeicher zugreifen um keine Skalierung mit HT oder SMT zu erzielen.
Gut ich bin schon länger aus dem Thema raus, aber hast du da einen Link diesbezüglich? Würde ich mir gerne mal ansehen.
 
AW: AMD Epyc Rome: Benchmark-Einträge listen 64-Kerner mit bis zu 2,2 GHz

Ah verstehe nun warum bei meiner Software ht nicht hinhaut. Warum ht ausbremst trotz das ich es auf 16 Kerne und somit 32 threads limitiert hatte es sich so aufzeigt. Mit ist aufgefallen das wenn ich 6 kerne abgeschaltet hatte von den 22 Kernen und ht eingeschaltet, das alle Kerne nur noch 50 % auslastung hatten. Bei 22 Kerne ohne ht ich aber 100 % auslastung. Die RAM Nutzung ist das Problem, jedoch daran ändern kann ich nix. Um fast 500 MB Arbeitsspeicher Nutzung zu erreichen müsste ich zwei Videos gleichzeitig umwandeln. Dafür habe ich 2x xmedia recode verwendet,mit H264. Wie es bei H265 aussieht kann ich nicht sagen, da ich diesen codec nicht verwende. Mit nur einem xmedia recode habe ich 200-250 MB Arbeitsspeicher Verbrauch. Also kaum der Rede wert. Somit verhindert die sehr geringe Nutzung des RAMs, eine vernünftige Nutzung von ht. Die Videos habe ich auf der ssd direkt drauf und werden auch auf der ssd darauf umgewandelt. Noch besser anbinden kann ich das ja dann auch nimmer. Ich habe quadchannel RAM. Ich dachte echt das mir das quadchannel was nützt. Bei Spielen macht sich das zwischen 2 und 4 RAMs dann doch zum Teil bemerkbar. Bei der Software wo es eigentlich ne massive mehrleistung geben sollte, jedoch merkwürdigerweise aber halt nicht. Dabei habe ich einen relativ hohen takt von 2400 er takt. Nur spielt das halt bei so ner mickigren RAM Nutzung halt nicht die so große Rolle wie ich dachte. Mir haben welche geraten ich solle das System aufs maximum ausnutzen. Hatte die Wahl zwischen 2133 und 2400 er RAM. Habe ich da etwa unnötig ein paar Euros zu viel ausgegeben?
 
AW: AMD Epyc Rome: Benchmark-Einträge listen 64-Kerner mit bis zu 2,2 GHz

Welche Anwendungen sind das genau? Davon höre zum ersten Mal im meinem Leben.
Wenn der Code cache-sensitiv ist, müsste ein Prozessor mit größeren Caches genau das Skalierungsproblem mit HT oder SMT aufheben.
Die Bedingungen damit SMT oder HT nicht skalieren müssen sehr viele Bedingungen erfüllt sein.
Deine Anwendung müsste Cache Misses permanent verhindern und selten bzw gar nicht auf den Arbeitsspeicher zugreifen um keine Skalierung mit HT oder SMT zu erzielen.
Gut ich bin schon länger aus dem Thema raus, aber hast du da einen Link diesbezüglich? Würde ich mir gerne mal ansehen.

Deswegen wird auch bei den meisten Supercomputing Zentren HT/SMT abgeschaltet. In manchen Anwendungsgebieten ist es ziemlicher Duktus, dass HT/SMT nichts bringt und man dieses lieber abschaltet. Um dies jetzt nicht ganz als blanke Aussagen hier in den Raum zu stellen hier zwei Standardreferenzen aus "meinem" Bereich:

1.) https://www.nas.nasa.gov/assets/pdf/papers/saini_s_impact_hyper_threading_2011.pdf
2.) https://www.nas.nasa.gov/assets/pdf/papers/NAS_Technical_Report_NAS-2015-05.pdf
 
AW: AMD Epyc Rome: Benchmark-Einträge listen 64-Kerner mit bis zu 2,2 GHz

Es macht nur Sinn wenn auf die Fließkommaeinheiten nicht zu sehr optimiert werden muss und diese ausgelastet sind, wenn ja fällt die Performance (GFLOPS) mit der niedrigeren Taktrate ab. Bis zu 128 Prozessen ist sie völlig gleich, ohne HT teilweise höher. Daher optimiert man eher darauf, z.B. bei Dual Racks mit 2x64C. Ab 144 würde HT Sinn machen.
 
AW: AMD Epyc Rome: Benchmark-Einträge listen 64-Kerner mit bis zu 2,2 GHz

Wenn es so eine Software gibt die mehr als 144 Kerne voll auslasten, aber da weiß aber auch keiner so genau ob ht/smt bremst oder wirklich beschleunigt. Man kann sich halt nur selten wirklich sicher sein, das auch wirklich alles so optimal optimiert worden ist. Aber gut, ist ja eh bekannt, das Software der Hardware hinterher hinkt, also von daher bestätigt das es sogar noch einmal mehr und unterstreicht das sogar noch. Könnte aber auch der zu hohen Komplexität geschuldet sein, das es für einige Software Entwickler ganz einfach ab einen gewissen Grad dann zu viel ist. Entwicklung ist nun mal sehr teuer. Und wenn es zu kompliziert ist, steigen gewiss manche Entwickler wohl aus. Oder es macht so viel Arbeit, das man ganz einfach die Lust an noch weiter zu optimieren, sie verloren haben. Ich nehme es den Entwicklern ja auch nicht übel. So ist das halt auf der Welt.
 
AW: AMD Epyc Rome: Benchmark-Einträge listen 64-Kerner mit bis zu 2,2 GHz

Es macht nur Sinn wenn auf die Fließkommaeinheiten nicht zu sehr optimiert werden muss und diese ausgelastet sind, wenn ja fällt die Performance (GFLOPS) mit der niedrigeren Taktrate ab. Bis zu 128 Prozessen ist sie völlig gleich, ohne HT teilweise höher. Daher optimiert man eher darauf, z.B. bei Dual Racks mit 2x64C. Ab 144 würde HT Sinn machen.

Woher kommt diese Schranke von 128 Prozessen?
 
AW: AMD Epyc Rome: Benchmark-Einträge listen 64-Kerner mit bis zu 2,2 GHz

Persönlich freuts mich eigentlich da ich eher an vielen Kernen interessiert bin als an vielen MHz. Vom Workload selbst her sind mir 16 Kerne bei 3 GHz (und 100W) deutlich lieber als 8 Kerne bei 4,5 GHZ (und 100W) und als Spieler der auf möglichst hübsche Grafik und 4K setzt ist CPU-Leistung ohnehin meist zweitrangig. Es wird langsam Zeit dass die Ryzen 3000er kaufbar werden - meine Notlösung i3-8100 hält sich zwar wacker mit aller Gewalt aber Spaß machts keinen. Die CPU ist jetzt seit mitte Januar im Einsatz und ich glaube den bereich unter 80% Last hat das Ding noch keine zwei Stunden gesehen. :ugly:
Hier aber am Rande positiv zu bemerken: Er frisst wirklich nur 30W. Ist zwar natürlich viel langsamer als sein Vorgänger 5960X aber effizienztechnisch ein ganz anderes Level. Ein Drittel bis teilweise fast die Hälfte der Performance bei unter einem Viertel des Stromverbrauches. Not bad.

Du hast dir einen Sockel-1151-Prozessor als Übergangslösung zu einem späteren AM4-System gekauft?
Da wäre ein Raven Ridge die naheliegendere Lösung gewesen, oder?


Es gibt auch beim Material physikalische elektrische und chemische Grenzen Stichwort Leckströme. Die in heutigen Cpus genutzten haben diese schon fast erreicht und es wird händeringend nach langfristigen Alternativen geforscht. Wenn ich mich recht erinnere meine ich gelesen zu haben das bei 3 - 5nm allerspätestens Schluss ist mit verkleinern. Auch was die möglichen Taktraten betrifft. Materialbedingt sind die Schaltzeiten der Transistoren in absehbarer Zeit auch an der Grenze des aktuell machbaren.

Beispiele für den 5-nm-Node werden bereits experimentell gefertigt, für 2,5 nm gibt es technologische Ansätze und einzelne Transistoren wurden bereits in 1 nm demonstriert. Trotz zunehmender Probleme sind heute genauso viele Full-Nodes absehbar, wie sie es vor 20 Jahren waren und es könnte durchaus sein, dass es danach noch weiter geht. Nur die Umsetzung in die Großserie wird immer schwieriger und langwieriger.

Taktraten sind heute übrigens kaum von Transistor-Schaltfrequenzen limitiert. Die heute verfügbaren 5 GHz waren schon für 65-nm-Großserientransistoren kein Problem, für heutige 7-/10-nm-Exemplare würden mich 8-10 GHz nicht überraschen. Aber die Kapazitäten der Verschaltungsebenen sind viel zu hoch, um Chips mit diesen Frequenzen zu bauen. Deswegen ist die Einführung von Cobalt-Metal-Layer durch Intel durchaus spannend.


Darf man fragen auf welchem OS du getestet hast? Mittlerweile ist ja schon ein paar mal berichtet worden, das Windows ab einer gewissen Anzahl an Cores (ob jetzt virtuell oder physisch) mehr oder weniger w.o. gibt.

Die von ihm geschildeter Skalierung spricht eigentlich für einen saubere Arbeit des Betriebssystems (und Fehlinterpretation durch den Anwender):
Auf einem Prozessor mit aktiviertem Hyperthreading liegt die maximal real erzielbare Auslastung bei 50 Prozent, da nur halb so viele Ausführungseinheiten wie Kerne vorhanden sind. Also arbeitet entweder jeder zweite logische Kern mit 100 Prozent oder jeder einzelne mit 50 Prozent (wobei letzteres meist ineffizienter ist). Werte darüber sind nur möglich, wenn der Träge Task Manager Wartephasen eines logischen Kerns nicht erkennt und als Arbeitszeit rechnet. (Was gerne und oft vorkommt, insbesondere bei schlecht optimierter Software mit vielen kurzen Leerlaufphasen – also genau das Seznario, für das SMT entwickelt wurde.)
 
AW: AMD Epyc Rome: Benchmark-Einträge listen 64-Kerner mit bis zu 2,2 GHz

Gut das dies nochmal geklärt wurde. Hat schon einer von euch mal probiert mit All-in-One-Skripts patches unter Windows 7 solche CPUs namens I9 7920,7940,i97960x oder gar I9 7980xe Windows 7 drauf zum laufen gebracht. Wäre nämlich für die Zukunft interessant, wenn ich bei Windows 7 festhalten will. Und dabei dennoch nicht auf mehr CPU Leistung zu verzichten zu müssen.
 
AW: AMD Epyc Rome: Benchmark-Einträge listen 64-Kerner mit bis zu 2,2 GHz

Interessanter ist eher, wie Ryzen 3000 mit Win7 läuft. Denn die sind deutlich günstiger und die derzeitigen AM4 Boards bekommen auch Win7 Treiber.
 
AW: AMD Epyc Rome: Benchmark-Einträge listen 64-Kerner mit bis zu 2,2 GHz

Interessanter ist eher, wie Ryzen 3000 mit Win7 läuft. Denn die sind deutlich günstiger und die derzeitigen AM4 Boards bekommen auch Win7 Treiber.

Supportende von Win7 ist am 14.01.2020. ich glaube nicht daß da noch irgendwas interessant ist.
 
AW: AMD Epyc Rome: Benchmark-Einträge listen 64-Kerner mit bis zu 2,2 GHz

Darum auch auf ältere bezogen. Da ich davon ausgehe, der treadripper 1950x wurde von smt gebremst. War genauso schnell wie der xeon e5 2699v4 mit ht. Halt nur bei meinem anwendungsfall. Der treadripper 2990 wx, bringt da auch nicht recht viel mehr mehrleistung. Beim core I9 7920x wäre ja nur ein Mini Update. Gehe mal davon aus das I9 9980xe das letzte ist wo man mit Tricks unter Windows 7 zum laufen kriegen können wird. Allerdings ist die 9000 Serie teurer als die 7000 Serie. Erst in sehr vielen Jahren erst günstiger. Die win 7 Treiber werden ja nicht verschwinden wenn Updates bei win 7 nimmer kommen. Und die CPU Abfrage zu umgehen bleibt wohl echt nur das Update Scripten übrig. Ich weiß nur halt nicht ob das so einfach geht und ob die CPUs alle Funktionen funktionieren. Denke mal die Funktion die die älteren haben werden die neueren auch voll verwenden können.
 
Zurück