News Ryzen Threadripper: 1950X und 1920X zu Preisen von 999 und 799 US-Dollar

[Pixelhomie]

Schon witzig. Da tut sich jahrelang rein garnichts auf dem CPU Markt, immer mit dem Hinweis 4 Kerne reichen vollkommen aus, und jetzt können es garnicht genug sein.

 

[Butter_b.d.F.]

Ja, ne ... als hätte ein Einzeller gerade realisiert, wie er sich zur Amöbe entwickeln und an Land kriechen könnte ...

 

[Phneom]

Schon witzig. Da tut sich jahrelang rein garnichts auf dem CPU Markt, immer mit dem Hinweis 4 Kerne reichen vollkommen aus, und jetzt können es garnicht genug sein.

Zum Zocken ja.
Wenn du aber mal weiter gehst wie z.b. rendern oder encoding sieht die Sache anders aus.
Beispiel:

@Xeon1231v3

 

[yurij]

AMD hat das gleiche Problem.

https://en.wikichip.org/wiki/amd/infinity_fabric

Problem?
Hier ist die längste strecke zwischen zwei beliebigen nodes (Dies) 2 hops.
Bei Intels Mesh wären es 4 hops.

CCX interconnect scheint hier zumindest so ziemlich das effizienteste was man sich bauen kann.
Das Problem hat eher Intels Mesh.

 

[Pixelhomie]

Zum Zocken ja.
Wenn du aber mal weiter gehst wie z.b. rendern oder encoding sieht die Sache anders aus.
Beispiel:
Anhang anzeigen 632823
@Xeon1231v3

Ich dachte rendern und encoding ist mit GPUs heute viel schneller und effizienter als mit einer CPU???

 

[Volkimann]

Schneller, aber qualitativ schlechter

 

[xexex]

Hier ist die längste strecke zwischen zwei beliebigen nodes (Dies) 2 hops.

Ja! So hat AMD die Architektur gestaltet. Das funktioniert dann aber nicht mehr wenn sie 4 oder 8 Sockel zusammenfügen wollen.

Deshalb sagte ich auch bereits, das man es nicht einfach hochrechnen kann. Bei 4 oder 8 Sockeln bräuchte AMD entweder eine Art Mesh zwischen den Sockeln oder eine neue Struktur und in beiden Fällen müssten sie die Anzahl der verfügbaren I/O Ports pro Die erheblich erhöhen. Das wiederum wäre für die einzelnen Kerne unsinnig und/oder teuer.

Ein Ryzen mit 64 PCIe Lanes als kleinste Einheit? Für viele sicherlich ein Traum, aber nicht gerade das was man massenweise mit hohen Gewinnen verkaufen würde.

 

[MK one]

Quantität = GPU , hohe Qualität = CPU

Wer sagt denn das AMD in den 4 - 8 Sockel Server Bereich will ? der Naples Nachfolger Starship hat schon 48 Kerne , im Dual Sockel = 96 Kerne 192 Threads , dazu Octachannel uns was weiß ich wieviel Terrabyte Ram ( Threadripper kann ja schon 2 TB adressieren )

 

[Phneom]

Ich dachte rendern und encoding ist mit GPUs heute viel schneller und effizienter als mit einer CPU???

Schneller ja aber dummerweise bekommst du größere Dateien dabei heraus und teilweise musst du Bitraten usw anpassen weil die Qualität auch einfach nicht so das wahre ist. Bei 3D Rendering je nach Effekte usw hast du da auch viel Berechnungszeit
Wenn du allerdings nen gutes Encoding Programm kennst was AMD unterstützt und diese Nachteile nicht hat würde sofort umsteigen. Soweit ich weiß lohnt GPU encoding nur zum streamen
Könnte auf GPU Basis encoden aber dann kann ich auch alles so lassen wie es ist
So ein 1600X würde meinen Kram deutlich schneller durchjagen. Selbst bei Audio Konvertierungen gibts Programme wie Taudioconverter die dir viele Audiodateien zur gleichen zeit umkonvertieren, damit bekomme ich die 8 Threads voll und die CPU läuft auch am Limit.
Dann kommt noch h265 und das ist noch CPU Intensiver beim encoding mal ganz davon abgesehen das viele Kerne bei Servern noch mehr Sinn machen.
Also ja viele Kerne lohnen sich bei richtiger Anwendung schon und wenn man mal hinschaut sieht man das sich der Singlewert kaum noch groß steigert ergo kommt man um Multicore wohl nicht drum herum.

 

[druckluft]

Hier ist die längste strecke zwischen zwei beliebigen nodes (Dies) 2 hops.

Ganz so wenige sind es dann doch nicht. Da hast du die Die-internen Routing-Punkte vergessen mitzuzählen

 

[Krautmaster]

Quantität = GPU , hohe Qualität = CPU

Wer sagt denn das AMD in den 4 - 8 Sockel Server Bereich will ? der Naples Nachfolger Starship hat schon 48 Kerne , im Dual Sockel = 96 Kerne 192 Threads , dazu Octachannel uns was weiß ich wieviel Terrabyte Ram ( Threadripper kann ja schon 2 TB adressieren )

niemand sagt das, aber es zeigt dass AMD und Intel hier auch verschiedene Märkte adressieren.

 

[aldaric]

Ist ja auch die logische Entscheidung für AMD. Man will erstmal im Markt wieder Fuß fassen, also geht man auf die größten Märkte im Serverbereich, diese sind mit großem Abstand 1 und 2 Sockel-Systeme.

 

[Krautmaster]

Ganz so wenige sind es dann doch nicht. Da hast du die Die-internen Routing-Punkte vergessen mitzuzählen

noch dazu spielt bei sowas auch die Signalausbreitungsgeschwindigkeit eine Rolle.

Assume a processor which works at 1GHz. This means one billion clock cycles per second. This also means one clock cycle takes one billionth of a second, or a nanosecond. Light travels about 30cm (about a foot) in a nanosecond. So, the size of circuitry involved at such clock speeds better be much less than (at least 1/10 of) 30cm. So, your maximum circuit size is 3cm. Taking into account that the actual CPU core size is less than 1cm a side, we are still in safe waters.

bei 3 Ghz schafft dein Signal vielleicht noch 10cm / Takt. Sinnvollerweise bleibt man aber deutlich darunter was die Leistungslängen angeht. Das ist bei mehreren Sockeln oder auch ganzen Racks also schon schwer. Nur weil man das Signal auf einer Die noch über diverse Hops routen muss muss es nicht zwingend langsamer sein.

Siehe Ryzen, es ist ja schon ein großer Unterschied zwischen CCX intern und CCC übergreifend.



Wäre interessant das mal auf ein Epyc und auf ein SLX System zu sehen.

Da gehen vom Takt viele Zyklen dazwischen rein, also potentielle Hops. Aufs Mesh sieht das so aus:

A core that access an L3-cache slice that is very close (like the ones vertically above each other) gets an additional latency of 1 cycle per hop. An access to a cache slice that is vertically 2 hops away needs 2 cycles, and one that is 2 hops away horizontally needs 3 cycles. A core from the bottom that needs to access a cache slice at the top needs only 4 cycles. Horizontally, you get a latency of 9 cycles at the most. So despite the fact that this Mesh connects 6 extra cores verse Broadwell-EP, it delivers an average latency in the same ballpark (even slightly better) as the former's dual ring architecture with 22 cores (6 cycles average).

Meanwhile the worst case scenario – getting data from the right top node to the bottom left node – should demand around 13 cycles. And before you get too concerned with that number, keep in mind that it compares very favorably with any off die communication that has to happen between different dies in (AMD's) Multi Chip Module (MCM), with the Skylake-SP's latency being around one-tenth of EPYC's. It is crystal clear that there will be some situations where Intel's server chip scales better than AMD's solution.

 

[itm]

1920X und Abfahrt.. wo bleiben die Benches

Leider wirds auch hier kein ITX geben so wie bei X99.. (jaja ich weiß es gibt genau 1! Mobo für X99)..

Es sind meines Kenntnisstand nach 2 gewesen wo LGA2011-3 draufgepasst hat.

Wie willst du bei dem TR4 Sockel noch mehr als 1 RAM Slot in ITX unterbringen (SO-DIMM tricksen zählt nicht).

Und das X99 Mainboard von AsRock (die Desktop Version) kriegt doch ein X299 Nachfolger...

 

[Krautmaster]

Schau dir die Stuktur beider An. Es kommt jetzt drauf an wie die Programme geschrieben sind.

Bei den Meisten Programme ist es so das es ausreicht wenn 4 Kerne miteinander Daten austauschen. Bei der CCX muss man im Programm also nur aufpassen das Threads die Daten von anderen Threasds brauchen in der selben Gruppierung laufen und bum das Teil wird viel viel Schneller abgearbeitet als bei Intel.

nochmal auf das zu kommen. Wenn deine Anwendung nur "4 Threads" hat dann kannst du bei AMDs MCM Design auch nicht einfach die Rohdaten der CPU anwenden. Dann hast du ein DualChannel Mode und auch weniger Cache.

http://www.anandtech.com/show/11544/intel-skylake-ep-vs-amd-epyc-7000-cpu-battle-of-the-decade/12



AMD hat zb eine sehr hohe Bandbreite bei einem Code, bzw bis 2 Threads.

The new Skylake-SP offers mediocre bandwidth to a single thread: only 12 GB/s is available despite the use of fast DDR-4 2666. The Broadwell-EP delivers 50% more bandwidth with slower DDR4-2400. It is clear that Skylake-SP needs more threads to get the most of its available memory bandwidth.

Meanwhile a single thread on a Naples core can get 27,5 GB/s if necessary. This is very promissing, as this means that a single-threaded phase in an HPC application will get abundant bandwidth and run as fast as possible. But the total bandwidth that one whole quad core CCX can command is only 30 GB/s.

Overall, memory bandwidth on Intel's Skylake-SP Xeon behaves more linearly than on AMD's EPYC. All off the Xeon's cores have access to all the memory channels, so bandwidth more directly increases with the number of threads.

Die Tabelle zeigt gut dass AMD für die Maximale Memory Performande die Threads uf verschiedene Die mit eigenem DDR Controller legen muss. Die Frage ist wie das Software seitig optimiert wird. Intel skaliert hier entsprechend über eine Die mit den Threads, ist linearer.

Thread zu Thread Latenz wäre AMD besser wenn die Threads in einer Die liegen, dann ist aber die Bandbreite wie man sieht auch auf Dual Channel limitiert.

Schön wäre das noch über mehrere Sockel zu sehen.

 

[MK one]

Ganz so wenige sind es dann doch nicht. Da hast du die Die-internen Routing-Punkte vergessen mitzuzählen

na dann zähl mal vor


es sind max 2 von Die zu Die oder auch nur 1 falls direkt verbunden , innerhalb des Die ist knifflig zu beantworten , kann jeder Kern direkt adressiert werden oder muss der CCX als Zwischenstation herhalten , hmm

 

[Krautmaster]

ich denke er meint das hier:

Previously, Ian has described the AMD Infinity Fabric that stitches the two CCXes together in one die and interconnects the 4 different "Zeppelin" dies in one MCM. The choice of using two CCXes in a single die is certainly not optimal for Naples. The local "inside the CCX" 8 MB L3-cache is accessed with very little latency. But once the core needs to access another L3-cache chunk – even on the same die – unloaded latency is pretty bad: it's only slightly better than the DRAM access latency. Accessing DRAM is on all modern CPUs a naturally high latency operation: signals have to travel from the memory controller over the memory bus, and the internal memory matrix of DDR4-2666 DRAM is only running at 333 MHz (hence the very high CAS latencies of DDR4). So it is surprising that accessing SRAM over an on-chip fabric requires so many cycles.

What does this mean to the end user? The 64 MB L3 on the spec sheet does not really exist. In fact even the 16 MB L3 on a single Zeppelin die consists of two 8 MB L3-caches. There is no cache that truly functions as single, unified L3-cache on the MCM; instead there are eight separate 8 MB L3-caches.

That will work out fine for applications that have a footprint that fits within a single 8 MB L3 slice, like virtual machines (JVM, Hypervisors based ones) and HPC/Big Data applications that work on separate chunks of data in parallel (for example, the "map" phase of "map/reduce"). However this kind of setup will definitely hurt the performance of applications that need "central" access to one big data pool, such as database applications and big data applications in the "Shuffle phase".

er meint nicht das routen innerhalb eines Package sonder das innerhalb einer Die, von einem CCX zum anderen CCX.

Schau dir den hervorragenden und nüchternen Test von Anandtech an. Es ist so wie gesagt. UseCases die einzelne Batches abfackeln oder zb auch VMs mit 8 MB L3 Slice laufen super. Sobald aber der L3 darüber hinaus Wichtigkeit bekommt, zb große Datenbanken, wirds schwerer von einem großen L3 zu sprechen.

Anandtechs Vermutung bestätigt sich ja auch ideal in den Benches. Zb Rendering ist Epyc überragend. Datenbanken weniger.

 

[druckluft]

@MK One: Selbst wenn du auf dem Die direkt jeden Core addressieren kannst, landest du von Die-2-Die bei 3 oder 4 Hops. Die Crossbars die dafür als Routing-Punkte nötig sind, zählen ja ebenfalls mit. Wie ich bereits zuvor schon geschrieben habe, man muß das im Vergleich zu Intels Mesh genauer (je nach Anwendung) analysieren wie sich das aus die Performance auswirkt. Das was ich hier schreibe ist erstmal völlig wertfrei, bevor ich dafür wieder angegriffen werde

 

[Krautmaster]

man sollte meinen dass fast alles hier wertfrei geschrieben wird ich finde Epyc und SL-SP zeigen gut dass es für beide Architekturen einen ideal Case gibt. Wenn man sich das bei 56/64 Kernen anschaut umso extremer.

Uns Customer dürften die Nachteile oder Bottlenecks kaum treffen. Weder Mesh noch IF+MCM Vor oder Nachteile bedeuten. Beide Architekturen bieten gute IPC an und eigen sich so auch gut zum Zocken. Intels i9 taktet höher, ist entsprechend da auch ineffizient aber hat nen Taktvorteil bei weniger Threads (hält den Turbo auf 4-4,5 Ghz auch bei allen 10 Kernen in fast jedem Fall), mal schaun was da der 12/16 Kern Threadripper macht.

Denke auch Intels 12-18 Kerner werden durch niedrigeren Base Takt die nötige Effizienz reinholen müssen. Für mich wirds interessant wie beide fern ab von Cinebench abschneiden, in einem Parcour der von wenig bis vielen Threads alle Usecases drin hat.

Wichtig ist auch den Verbrauch bei Teillast zu testen.

 

[kisser]

der Naples Nachfolger Starship hat schon 48 Kerne , im Dual Sockel = 96 Kerne 192 Threads ,

Und wenn das nicht reicht, was dann? Niemand wird sich dann 2 Dual-Sockel-Systeme statt eines Quad-Sockels-Server hinstellen, weil sich das erstens nicht rechnet und zweitens nicht jede Anwedung problemlos über mehrerere System skaliert.