News Ryzen Threadripper: Drei Modelle mit 16, 12 und 8 Kernen offiziell vorgestellt

seh ich auch so 16 Kerne braucht man nicht für s Gaming , klar man kann auch Gamen dank Turbo auf ein oder 2 Kernen , jedoch braucht man die Multicore Power von 16 Kernen dort nicht wirklich .

Coffeelake s 6 Kerner macht da vermutlich viel mehr Sinn , wenn man nur Gaming betrachtet ...
 
Der_Unbekannte schrieb:
geht es mir nicht um die Anzahl der Kerne, sondern um den FAKT(!), das es im Consumer-Bereich bereits eine CPU mit ähnlichen Spezifikationen und damit ähnlicher Leistung gibt, was den Entry Level HEDT Prozessor obsolet macht.
Der_Unbekannte schrieb:
Die Anzahl der User, die nur die Lanes oder den Quad Channel brauchen, dürfte schon so gering sein,
Bei Quadchannel-Speicher könnte ich dir zustimmen, das bringt wirklich nur in Ausnahmefällen etwas.
Die zusätzlichen PCIe-Lanes sind aber ein ganz massiver Vorteil von Threadripper gegenüber den AM4-Ryzens.

Die Entwicklung bei Storage geht klar Richtung PCIe. 10-Gigabit-Ethernet ist bei zwei X399-Mainboards standardmäßig dabei (einmal onboard und einmal als Erweiterungskarte). Im High-End Bereich ist M.2 RAID0 zunehmend verbreitet. Mit AM4 ist all das nur eingeschränkt oder mit Kompromissen möglich.

Ich gehe davon aus, dass AM4 mangels ausreichender I/O-Möglichkeiten ziemlich bald für den High-End/Enthusiast/Prosumer-Bereich uninteressant sein wird, selbst in Anwendungsgebieten wo 8 Kerne erstmal genug sind.
 
Was wenn es bei Quad channel nicht um die höhere Bandbreite sondern einfach den größeren maximalen Speicherausbau geht?
 
@unbekannte
Denke AMD weiß wieso sie ein Produkt anbieten.
Vemute auch stark, dass sich der 1900x besser verkauft als die 12+ Kerner. Er ist günstiger und bietet dieselbe unbeschnittene Plattform. Zudem brauchen viele Leute einfach keine 12+ Kerne.

Hätte AMD "den Intel" gemacht und den 1900x beschnitten auf die Plattform gebracht wäre er sicher eine Totgeburt.

@shadow
Sowohl als auch.
 
@Shadow Complex
Für maximalen Speicherausbau gibt's dann Epyc, der 24-Kern 7401P kostet etwa gleich viel wie der Threadripper 1950X und unterstützt sogar LR-DIMMs (Threadripper zumindest offiziell nicht). Der 16-Kern 7351P kostet etwa soviel wie der 1920X.
 
Der_Unbekannte schrieb:
Die Anzahl der User, die nur die Lanes oder den Quad Channel brauchen, dürfte schon so gering sein, das man allein den Aufwand für den 1900X aus AMD-Sicht mehr bezahlt, als er durch Verkauf an diese Personen wieder einnehmen würde.
Aha, was genau kostet es einfach nochmal einen Kern pro CCX abzuschalten? Exakt gar nichts.

Der_Unbekannte schrieb:
Bezüglich L3 des 1900X: Ich wäre mir da mal gar nicht so sicher, das der 1900X mit mehr als 16mb L3 daherkommt, wie man hier entnehmen kann:

http://wccftech.com/amd-ryzen-threadripper-1900x-1920x-1950x-official/

Sollte das so zutreffen, spricht noch nicht mal ein höherer L3 cache für den 1900X.

Allein die Logik der gleichmäßig deaktivierten CCX ergibt die 32MB L3 Cache. Ansonsten wäre der Preis nicht zu rechtfertigen.
Was von WTFTech als Quelle zu halten ist, dürfte wohl eh klar sein :rolleyes:
 
(4+0) + (4+0) mit insgesamt 16MB ist schneller als (2+2) + (2+2) mit insgesamt 32MB

Der L3 Cache hängt bei AMD nicht zusammen. Ist daher genaugenommen auch nicht einfach addierbar. Die L3 Latenz innerhalb eines CCX (0 - 8MB) ist richtig flott. Sobald es aber zum L3 Block des zweiten CCX auf dem gleichen Chip geht (8 - 16MB) ist der Zugriff kaum schneller als DRAM und Chip to Chip ist entsprechend noch etwas langsamer.
 
Zuletzt bearbeitet:
YforU schrieb:
Sobald es aber auch nur zum L3 des zweiten CCX auf dem gleichen Chip geht ist der Zugriff kaum schneller als DRAM.

Wenn du sowas behauptest, dann beleg es bitte auch.
 
Quelle: http://www.hardware.fr/articles/956-23/retour-sous-systeme-memoire.html

Im Detail: http://www.hardware.fr/getgraphimg.php?id=445&n=2

Oberhalb von 8MB L3 (damit Zugriff auf den Cache Block des zweites CCX) beträgt die Latenz ~100ns. Größer 16MB ist dann DRAM (DDR4).

Im Vergleich dazu Broadwell-E: http://www.hardware.fr/getgraphimg.php?id=445&n=1

Der L3 Cache mit 20MB ist effektiv ein Block und daher bleibt die Latenz identisch bis dessen Kapazität nicht mehr ausreicht. Danach DRAM.
 
Zuletzt bearbeitet:
Dir sollte klar sein, dass mit schnellerem Ram und durch Agesa Updates sich die Zugriffszeiten verkürzt haben Richtung ~70ns. Release-Artikel als Referenz nehmen, wo man wusste das noch was schief läuft ist leider nicht die beste Idee.
 
@ottoman
Angenommen ein Spiel erzeugt eine Last von 400% auf der ganzen CPU (1 Kern = 100%). Dann weiß man nur, dass es mindestens 4 Threads sind. Auch wenn diese durch den Scheduler vielleicht auf 8 Kerne verteilt werden und es aussieht wie 8 Threads.

Jetzt vermute, dass ich langsam weiss, worauf Du rauswillst.

Da müssen wir aber etwas ausholen:
1.Der Begriff Thread ist zweideutig. Es gibt die virtuellen Threads auf einer CPU=2 Stück auf einen Core
2.Es gibt die Bezeichnung kleinerer Unabhängiger Programme, die einen Thread abbilden.
Durch den Scheduler können viele dieser Subroutinen (Threads) unter Anderem auf einem Core- Thread konsolidiert werden oder aber auch verteilt.

Jetzt kommt aber der Punkt. Wäre das Programm nicht auf Multithreading sowohl auf Programm als auch auf Core- Basis optimiert,
würden wir Szenarien erleben, in denen die Command oder Mainthreads ihre Last nicht weiterverteilen, da sequenziell abgebildet.

Bei einer 4 Core- CPU mit HT, optimiert auf 4 Threads sähe das dann so aus:
70% 4% 80% 1% 4% 30% 66% 3%

Dieses Szenario werden sicher einige wiedererkennen ;)

Die Zahlenreihen können beliebig untereinander wechseln, Du wirst aber immer Threads sehen, die nicht ausgelastet werden können.
Dann ist es eine Sache der Messung. Der Afterburner aktualisiert immer den ist- Zustand an einem Messpunkt. Er mittelt also keine Werte.

Es gibt Witcher 3 Videos, da geht unter einem älteren 6- Kerner die Last auch auf bis zu 80% rauf (mit 2x1080 TI).
Spätetens bei solchen Auslastungen steht Deine Argumentation, dass die Software nicht Multicore/Multithreading optimiert ist auf wackeligen Beinen, da dem Scheduler die Wahlmöglichkeit genommen wird, auf "freie" Threads auzuweichen und diese zu pushen, obwohl die anderen Threads, die unter Last stehen, vielleicht noch ein wenig Restkapazität über hätten.

Grüße
Zero
 
Zuletzt bearbeitet:
Aldaric87 schrieb:
Dir sollte klar sein, dass mit schnellerem Ram und durch Agesa Updates sich die Zugriffszeiten verkürzt haben Richtung ~70ns. Release-Artikel als Referenz nehmen, wo man wusste das noch was schief läuft ist leider nicht die beste Idee.

Das ändert nichts grundlegendes. Ob 100 oder 70ns spielt hier keine Rolle denn 15ns innerhalb eines CCX sind eine andere Größenordnung.
 
Das ändert sehr wohl grundlegendes, da der 6800/6900k auch 70 ns hat laut deinem hardware.fr Test.

Demnach scheint ja der Ring-Bus kaum Vorteile gegenüber dem Infinity Fabric zu haben, zumindest in der Latenz.
 
Zuletzt bearbeitet:
Es geht nicht um die DRAM Latenz sondern um die L3 Cache Latenz. Innerhalb eines CCX und von CCX zu CCX.
 
Zuletzt bearbeitet:
Ja, dabei geht es doch um CCX zu CCX L3 und nicht innerhalb. Wie man sieht hat der Ring-Bus kaum Vorteile in der Latenz. Wo ist also der Nachteil bei der Inter-CCX Kommunikation ?
 
Es ging hier nicht um Intel sondern weshalb ein TR 1900X mit 16MB L3 flotter ist als einer mit 32MB.

YforU schrieb:
(4+0) + (4+0) mit insgesamt 16MB ist schneller als (2+2) + (2+2) mit insgesamt 32MB

...

Broadwell-E habe ich zur Verdeutlichung genommen um zu zeigen wie es aussieht wenn man einen zusammenhängenden L3 Cache hat. Die Latenz ist hier gleichbleibend bis der gesamte Cache voll ist.

OK, 4 Kerne und 8MB L3 liegen in einem CCX. Die L3 Latenz für diese vier Kerne auf ihren Cache ist sogar noch etwas geringer als bei Broadwell-E (~15ns). Muss aber einer dieser Kerne Daten aus dem L3 Cache des anderen CCX holen sitzt man auf DRAM (Arbeitsspeicher) Niveau (~84ns bei DDR4 2667). Langsamer geht bezogen auf L3 nicht und daher bringt der Cache des einem CCX dem anderen kaum etwas.

Genau aus dem Grund gab es diverse Patches um die Performance in Spielen/Anwendungen zu verbessern. Threads unnötig zwischen den CCX hin und her zu schieben kostet ordentlich Performance. Völlig vermeidbar ist es aber nicht und Daten liegen nunmal auch im "falschen" L3 Block.
 
Zuletzt bearbeitet:
rg88 schrieb:
Aha, was genau kostet es einfach nochmal einen Kern pro CCX abzuschalten? Exakt gar nichts.



Allein die Logik der gleichmäßig deaktivierten CCX ergibt die 32MB L3 Cache. Ansonsten wäre der Preis nicht zu rechtfertigen.
Was von WTFTech als Quelle zu halten ist, dürfte wohl eh klar sein :rolleyes:

Wie wärs, wenn du dir mal die offizielle AMD Folie ansiehst? Allein, das AMD bis zu 68 Prozent mehr Cache gegenüber dem 7900X stellt, während der 7900X schlappe 5 Prozent mehr gegenüber dem 7820X mehr Cache hat, sagt bereits alles.
AMD zählt L2+L3 als Gesamtcache. Dadurch komme ich auf 20MB, was auch auf meiner Ryzen 7 Box steht (8x512KB+16MB). Der 7820X verfügt daher über 19MB (8x1MB L2 +11MB L3). Also fehlt dem 7820X 1/20tel vom cache, was den angegeben 5 Prozent entspricht.
Somit hat der 7900X genau so viel Cache wie der Ryzen7.
Ich gehe immer nach Fakten, nie nach Behauptungen.
 
Liefer mal Fakten, dass HEDT useless ist, so wie von dir propagiert :-)
 
Ich habe genügend Argumente geliefert. Wenn du das nicht verstehen kannst, dein Problem.
 
Deine Argumente waren aus meiner Sicht aber absolut an den Haaren herbeigezogen, da du gar nicht auf das Nutzungsverhalten anderer eingehst und in Betracht ziehst, dass es sinnvoll sein kann, die HEDT Plattform mit dem 1900X zu nutzen.
 
Zurück
Oben