Test Ryzen Threadripper 2000 im Test: 32 Kerne sind verrückt, 16 sehr gut nutzbar

@CB
Mal abseits der Sicherheits und Latenzdisskusion würde ich gerne mal die Benchmark Karte/Treiber in Frage stellen, es gab ja schon oft die vermutung das NV mit vielen Kernen Probleme macht, aber jetzt hat mal es endlich mal bestätigt.

Ich fände es sehr gut wenn sich CB auch mal die Sache anschaut!!

(Spekulation: Daher kommt wohl auch der Glaube das AMD CPU+GPU schneller ist)
 
  • Gefällt mir
Reaktionen: Smartcom5 und -Ps-Y-cO-
Also ich würde jetzt eine AMD CPU, die im Grunde seit 1 Jahr auf den Markt ist und jetzt einen Refresh erhalten hat, nicht mehr als Exoten bezeichnen. Eher würde ich es als ungewöhnlich und revolutionär bezeichnen, das es im Consumerbereich jetzt CPUs gibt die mit so vielen Kernen daher kommen, zu einem Preis der eben weit unter dem liegt, was bisher für eine ähnliche Kernzahl gefordert wurde.
Wenn es wirklich am Scheduler von Windows liegt, dann hat MS entweder gepennt, oder das Problem ist nicht so einfach zu lösen wie man vermutet. Oder das Interesse war zu gering sich darum zu kümmern. Ist auch am Ende egal. MS wird sich mit Hilfe von AMD darum kümmern, denn Linux zeigt das es geht.

@oldmanhunting
Mir fällt wieder ein mal auf, das du einfach ein unverbesserlicher kleiner Hater bist. Ist das für dich eine Art Hobby immer wieder, egal ob CPU Bereich oder GPU Bereich, solche Spitzfindigen Posts zu setzen, wo es nur darum geht gegen Firma/Produkt XY zu schießen. Zwar ganz nett verpackt, aber wenn man es mal auf das wesentliche reduziert, liest man echt nichts positives.
 
  • Gefällt mir
Reaktionen: Smartcom5 und HaZweiOh
Zur Info :
Der oft genannte Spruch mit " Intels Schublade " und in die Intel nur zu greifen bräuchte , stammt von ihm ... :D
 
  • Gefällt mir
Reaktionen: Hill Ridge
Volker schrieb:
Habs mal bei uns kurz gegengetestet. Unterschied: Golem testet zudem nur in 720p, wir machen 1080p.

Kingdom Come habe ich auch einen Unterschied, von 41,7 auf 45,6 FPS (1080 Ti zu Vega 64)
Project Cars 2 von 52,3 auf 58,1
Warhammer von 9,9 auf 10,1 ^^

Also ja, Vega kann was besser machen. Aber nicht den heiligen Gral finden.

Eine Verdoppelung der Frameraten und massive Gewinne in 4 von 5 Spielen hören sich aber schon durchaus so an! Und ist die Vega64 nicht schon grundsätzlich langsamer als die 1080Ti wird in diesem Fall aber sogar deutlich schneller? Demnach müsste man noch grob 35% für den Performance Unterschied der Karten drauflegen.

Wenn eine Vega64 plötzlich teilweise doppelt so schnell ist wie eine 1080Ti gehen da keine Alarmglocken an? Ich mein diese super schrillen.
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: surtic
Ned Flanders schrieb:
Intel has shifted to a non-inclusive L3 cache structure, which means that the L2 cache lines may not be in the share L3 Cache

Ich habe es glaube ich jetzt zig mal erklärt!

Non-Inclusive heisst, der L2 Cache wird NICHT im L3 Cache gespiegelt und es steht jedem Kern der volle L2 UND L3 Cache zur Verfügung. Die Daten landen im L3 Cache wenn sie im L2 Cache nicht mehr benötigt werden. Das geschieht unter anderem dann, wenn ein Prozess auf einen anderen Kern umgeschaltet wird.

Ned Flanders schrieb:
Warum sollte ein Kern sich die evicted Data eines anderen Kerns holen außer der Prozess wird vom Scheduler weitergereicht

Wieso außer? Es ist einer der Hauptgründe dafür wieso man ein Cache so gestaltet. Eine CPU schaltet ständig zwischen verschiedenen Prozessen hin und her und ein Prozess muss nicht zwingend immer auf dem gleichen Kern landen.

Ned Flanders schrieb:
Und warum hat das keinen dramatischen Performance impact wenn die Architektur ständig Cachemisses hat?

Es HAT einen Leistungsnachteil zur früheren Architektur. Trotzdem sind die Daten zig mal schneller aus dem Cache geholt als aus dem Speicher. Was passiert wenn die Daten ständig neu aus dem Speicher geholt werden müssen siehst du bei dem TR WX Test unter Windows.

Ein Ryzen ist davon nur teilweise betroffen, beim Threadripper hast du aber gleich 4 Dies von denen zwei gar keine direkte Speicheranbindung haben und um diese "seltsame" Konfiguration zu bedienen, muss man eben viel mehr Aufwand wie bei Intel betreiben.

Der Speicherzugriff sieht schon bei EPYC problematisch aus, und beim TR WX dürfte es noch extremer ausfallen.
1534348858374.png

https://www.anandtech.com/show/11544/intel-skylake-ep-vs-amd-epyc-7000-cpu-battle-of-the-decade/12
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: Krautmaster
xexex schrieb:
Ich habe es glaube ich jetzt zig mal erklärt!

Non-Inclusive heisst, der L2 Cache wird NICHT im L3 Cache gespiegelt und es steht jedem Kern der volle L2 UND L3 Cache zur Verfügung.

Was Du beschreibst ist eine exclusive Cache Policy. Skylake SP hat aber eine non-inclusive cache policy (NINE).

Es ist nicht meine Schuld, dass du den Unterschied nicht kennst. Das nervt mich auch nicht, aber das patzig sein stört.

Dark_Knight schrieb:
@oldmanhunting
Mir fällt wieder ein mal auf, das du einfach ein unverbesserlicher kleiner Hater bist.

Der alte Mann ist ein Fan was er auch offen zugibt. Find ich völlig ok. Kisser ist ein Hater. Da muss man schon Differenzieren!

Schönen Feierabend allerseits.
 
Zuletzt bearbeitet:
Ned Flanders schrieb:
Was Du beschreibst ist eine exclusive Cache Policy. Skylake SP hat aber eine non-inclusive cache policy (NINE).

https://en.wikipedia.org/wiki/Cache_inclusion_policy
https://en.wikipedia.org/wiki/Victim_cache

Re-architected L2/L3 cache hierarchy:
  • Each CPU core contains 1MB L2 private cache (up from 256KB)
  • Each core’s private L2 acts as primary cache
  • Each CPU contains >1.3MB/core of shared L3 cache (for when the private L2 caches overflow)
  • The shared L3 cache is now non-inclusive (does not keep copies of the L2 caches)
  • Larger 64-entry L2 TLB for 1GB pages (up from 16 entries)
https://www.microway.com/knowledge-...sp-intel-xeon-processor-scalable-family-cpus/
 
Zuletzt bearbeitet:
@xexex

"non-inclusive" ist nicht das selbe wie "exclusive". Das steht doch selbst in deinem Wiki Artikel.

Intel nennt das Ding "non-inclusive". Wo sind hier offene Fragen? Meinst Du Intel ist zu doof die eigene Cache Hierarchie treffend mit "exclusive" zu beschreiben wenn sie das wäre? Der L3 Cache enthält nicht den gesamten Inhalt des L2 wie bei einem Inclusive Design, aber eben auch nicht garnichts davon (das wäre eben exclusive).

Deswegen auch:

Intel has shifted to a non-inclusive L3 cache structure, which means that the L2 cache lines may not be in the share L3 Cache

UND

  • The shared L3 cache is now non-inclusive (does not keep copies of the L2 caches)
Sprich es ist eine Logik am Werk, die entscheidet was drinn bleibt und was nicht und da Du und Ich diese nicht kennen....:

Ned Flanders schrieb:
.... ist es halt sehr schwer zu bestimmen wie groß der L3 Cache effektiv ist ohne zu wissen was Intel mit "non-inklusive" meint. Außer bei Skylake-SP ist es ja sowieso ein inklusiver Cache und damit effektiv kleiner je Kern (beim 8700k (12-1.5)/6=1.75mb/Kern) gegen (2x8/8=2mb/Kern beim 2700x bzw noch mehr beim 2600x)). Er scheint ja zumindest nicht exclusive zu sein, denn so hätte man das traditionell genannt.

Das ist auch keine neu Erfindung des Rades... AMD hatte meines Wissens nach beim Opteron auch schon non-inclusive L3 Caches.
 
Zuletzt bearbeitet:
Ich weiß nicht an welchen Punkt wir einander vorbei reden!

1534352177281.png

Inclusive war der Cache bisher und ist in der Mitteklasse noch immer. Dabei sind die Daten vom L2 Cache auch im L3 Cache gespiegelt und der effektive L3 Cache ist kleiner.

Non-inclusive ist der jetzt, dabei steht jedem Kern ein voller L2 UND L3 Cache zur Verfügung und die Daten im L2 Cache stehen nie im L3 Cache.

Der L3 Cache ist dabei als Victim Cache ausgelegt, er wird nicht direkt befüllt sondern Daten die nicht mehr im L2 Cache benötigt werden landen dort und können von anderen Kernen geladen werden.
 
Zuletzt bearbeitet:
@xexex

Vieleicht ist es einfacher wenn du selbst mal den Unterschied zwischen einer non-inclusive und einer exclusive Architektur erklärst.

btw: may notmust not oder do not
 
Vielleicht erklärst du es selbst mal, wenn du der Meinung bist es gibt dort einen entscheidenden Unterschied.

1534353113726.png

https://www.researchgate.net/public..._for_flexible_and_efficient_cache_hierarchies

Non-Inclusive = exclusive wenn es darum geht, dass sich in beiden Caches unterschiedliche und NICHT die gleichen Daten befinden. Es KÖNNEN sich die gleichen Daten dort befinden, sie werden jedoch nicht zwangsweise wie beim Inclusive Cache dorthin gespiegelt.

Was ändert das an der bisherigen Aussage? Es stehen jedem Kern noch immer der volle L2 und L3 Cache zur Verfügung, während beim Inclusive Cache der L2 Cache vom L3 abgezogen werden muss.
 
Zuletzt bearbeitet:
xexex schrieb:
Es KÖNNEN sich die gleichen Daten dort befinden, sie werden jedoch nicht zwangsweise wie beim Inclusive Cache dorthin gespiegelt.

Here you go! Und sie schließen sich auch nicht aus wie beim exclusiven design. exclusive = do not ; non-inclusive = may

1534353586660.png


Altes Paper zum Opteron: Hackenberg et al., 2009, Comparing Cache Architectures and Coherency Protocols on x86-64 Multicore SMP Systems

Damit hoffe ich können wir den Fall jetzt abschließen. Die effektive Größe hängt von einer Logik ab über die wir zu wenig wissen um sie beurteilen zu können.
 
Und worüber diskutieren wir? AMD hat praktisch die gleiche Cache Architektur. Der Unterschied ist nur, dass es ein L3 Cache pro CCX gibt während er bei Intel von allen Kernen gemeinsam genutzt wird. Ich habe nie behauptet Intel hätte was neues erfunden, der L2 Cache ist aber doppelt so groß und auf den L3 Cache können alle Kerne zugreifen.

Ein Switch von CCX zu CCX bedeutet bei AMD, dass die Daten neu vom Speicher geholt werden müssen und das kostet Zeit und viel mehr Takte als ein Zugriff auf den L3 Cache.
 
Zuletzt bearbeitet:
xexex schrieb:
Und worüber diskutieren wir?

Wir haben das diskutiert, weil deine Aussage falsch war und du keine Ahnung hattest von was ich rede aber Oberlehrermäßig meintest mich aufklären zu müssen das non-inclusive das gleiche wie exclusive ist. Du kannst das ja nochmal durchlesen wenn dein Gedächnis da zicken macht.
 
  • Gefällt mir
Reaktionen: ottoman und Sester
Ned Flanders schrieb:
Wir haben das diskutiert, weil deine Aussage falsch war und du keine Ahnung hattest von was ich rede aber Oberlehrermäßig meintest mich aufklären zu müssen das non-inclusive das gleiche wie exclusive ist. Du kannst das ja nochmal durchlesen wenn dein Gedächnis da zicken macht.

Für den Ton entschuldige ich mich gerne, aber Worte in den Mund legen möchte ich mir trotzdem nicht.

1534355143472.png


1534355037283.png

Wo habe ich etwas von exclusive gesagt?

Deine Aussage ist hingegen falsch!
1534355256399.png

Das die Daten vom L2 nicht im L3 Cache gespiegelt werden treffen sowohl auf non-inclusive als auch auf exclusive Cache zu, sie werden nur beim non-exclusive nicht invalid markiert sobald der Inhalt in den L2 Cache kopiert wird. Auf die Angabe der Cachegröße hat dieser Unterschied jedoch keine Bedeutung, es steht in beiden Fällen der volle L2 und L3 Cache zur Verfügung.
 
xexex schrieb:
Das die Daten vom L2 nicht im L3 Cache gespiegelt werden treffen sowohl auf non-inclusive als auch auf exclusive Cache zu, sie werden nur beim non-exclusive nicht invalid markiert sobald der Inhalt in den L2 Cache kopiert wird.

Na dann hast du es ja jetzt wenigstens verstanden. Hat es sich doch gelohnt.

Gruss,

Ned
 
Hill Ridge schrieb:
Was ist daran spannend?

NVIDIA hat es einfach verpennt, den Treiber fit für 64T zu machen!


Jop und da fast alle Testseiten Spiele mit einer gtx 1080ti getestet haben sieht der große da doppelt doof aus^^
 
Zurück
Oben