News 3D V-Cache Technology: AMD stapelt L3-Cache bei Ryzen auf 192 MByte

TheCrazyIvan schrieb:
Die schmeißt AMD nicht einfach weg, sofern es noch einen sinnvollen Markt (inkl. Ersatzteilgeschäft) für Zen 2 gibt
Natürlich gibt es dafür noch einen Markt, den hat man sich aber ja bewusst so offen gelassen für Zen2, indem man im unteren Preisbereich garkein Zen3 anbietet.

chithanh schrieb:
Bist du sicher, dass das noch nennenswert passiert?
Zumindest beim 3600 hat es stark den Anschein, da der Ende letzten Jahres ja auch sehr schlecht verfügbar war und mittlerweile wieder gut zu haben ist. Und auch beim 3100 warten die Händler wohl auf die nächste Lieferung.

Aber was du sagst macht durchaus Sinn, dass das hauptsächlich CPUs sind, die bei den Server-CPUs aussortiert wurden. Da passt es auch ins Bild, dass der 3300X mit einem vollaktiven CCX nicht mehr zu haben ist. Von den größeren CPUs (3700X aufwärts) hat man dagegen ja ein Zen3-Pendant - da kann ich mir schon vorstellen, dass da nix mehr produziert wird.
 
SV3N schrieb:
Ich kann mir beim besten Willen nicht vorstellen dass AMD das tote Pferd AM4 nochmal mit einer solchen Innovation reiten wird.
Ich sehe das so: EDIT Für Consumer /EDIT macht sich Cache hauptsächlich bei Spielen bemerkbar, bei Anwendungen eher wenig bis gar nicht. Bei Anwendungen hat AMD zur Zeit auch kein Problem mit Intel. Gaming ist der Bereich, wo man sich auch weiterhin mit Intel um die Führung prügeln muss.
Threadripper ist ein Nischenprodukt mit geringen Verkaufszahlen und primär nicht fürs Gaming konzipiert.
Bis AM5 ist es noch relativ weit. Außerdem kann ich mir vorstellen, dass viele lieber erstmal noch auf eine ausgereifte Plattform setzen und abwarten, bis die neue Plattform ihre Kinderkrankheiten abgelegt hat.
So tot ist das Pferd also noch nicht, dass man absteigen müsste.

Die Chiplets werden eh produziert, und selbst wenn sie vorrangig für TR gedacht sein sollten, da werden bestimmt noch welche übrigbleiben, weil TR nicht diese Stückzahlen hat.
Also warum nicht die AM4-Topmodelle bis dahin nochmal upgraden, um Intel im Bereich Gaming nochmal ein wenig zu ärgern.
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: jemandanders und bikkje
latiose88 schrieb:
Das heist je weniger ich da an instuktionen verwende desto schlechter wird wohl auch instuktionen pro taktzyklus sein. Man kann also selbst die ipc sehr wohl beeinflussen wie es scheint
Selbstverständlich, wäre das nicht so, würden wir überall die gleiche IPC sehen.
Deshalb hast du ja Anwendungen wo die IPC um 30% steigt und andere wo sie nur um 9% steigt.
 
  • Gefällt mir
Reaktionen: Colindo
Shadak schrieb:
https://de.wikipedia.org/wiki/Instructions_per_Cycle
fürs nächste mal schnell googlen oder wiki fragen. reduziert die gefahr peinlicher aussagen^^

Du hast recht ;)
Mit Cycle ist natürlich der „Clock Cycle“ gemeint, die Abkürzung reduziert das zu „Cycle“
Der englische Wikipedia Eintrag zu IPC schreibt übrigens „In computer architecture, instructions per cycle (IPC), commonly called instructions per clock is one aspect of a processor's performance: the average number of instructions executed for each clock cycle. It is the multiplicative inverse of cycles per instruction.[1]

https://en.wikipedia.org/wiki/Instructions_per_cycle

Insofern kann man beides synonym verwenden und fällt auch im Gespräch auf Konferenzen zu Prozessor Architekturen nicht negativ auf.

Es ist in jedem Fall richtiger als „instructions per core“
 
  • Gefällt mir
Reaktionen: Colindo
[wege]mini schrieb:
Stuffz schrieb:
Aber muss ich da nicht irgendwo einen Tag-Ram-Chip einbauen, damit überhaupt mehr als 64mbit vim Käsch gekäscht werden können?
Warum sollte dies so sein?
früher™ brauchte man den tag-ram, damit der ram überhaupt cachable war und man musste dafür sorgen, dass dieser zur grösse des rams passte (was bei intels fx & tx chipsatz dazu führte, dass evtl. nicht der gesamte ram cachable war und die leistung einbrach). aber die zeiten sind doch schon etwas länger vorbei :)
 
  • Gefällt mir
Reaktionen: konkretor und [wege]mini
Balikon schrieb:
Ich sehe das so: Cache macht sich hauptsächlich bei Spielen bemerkbar, bei Anwendungen eher wenig bis gar nicht.

Ich würde sagen, das kommt auf die Anwendung an. Z.B. ob sie eher aus Numbercrunching besteht, oder eher I/O-lastig ist usw.
Nicht umsonst haben viele Server-CPUs außergewöhnlich große Caches. Und das war wohl auch einer der Gründe, warum die ersten Extreme- und FX-CPUs umbenannte Server-CPUs waren.
 
  • Gefällt mir
Reaktionen: Balikon und [wege]mini
Dome87 schrieb:
Hubraum, leider geht bei KFZ der Weg in die entgegengesetzte Richtung :/
Nur das hier auch die "IPC" gestiegen ist.

Aber schön, das AMD nicht stehen bleibt
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: konkretor
@Herdware Danke für den Hinweis. Nun sind Server-CPUs keine Consumerprodukte. Wenn ich meine Aussage auf Consumer beschränke, trifft sie eher zu, oder?
 
0x8100 schrieb:
früher™ brauchte man den tag-ram, damit der ram überhaupt cachable war und man musste dafür sorgen, dass dieser zur grösse des rams passte (was bei intels fx & tx chipsatz dazu führte, dass evtl. nicht der gesamte ram cachable war und die leistung einbrach). aber die zeiten sind doch schon etwas länger vorbei :)

Tag-RAM braucht man noch immer, fuer jede Cache-line muss ja gespeichert werden, fuer welche Hauptspeicheradresse sie derzeit den Inhalt enthaelt. Aber das ist schon laenger kein separater Chip mehr, sondern in den Cache integriert. Ich wuerde erwarten, dass die Tags fuer die zusaetzlichen 64MB auf auf dem Zusatz-Die liegen, aber es ist natuerlich auch moeglich, dass sie auf dem CCD liegen und stillgelegt sind, wenn's kein Extra-Cache-Die gibt.

Dass die 64MB soviel Platz brauchen wie die 32MB auf dem CCD, koennte auf Tags auf dem CCD hindeuten. Eine andere Erklaerung (die ich fuer plausibler halte) waere, dass auf den Cache-Chip nur kurze Leitungn bis zum TSV gibt und man sich damit den Platz fuer lange Leitungen und die Treiber fuer diese Leitungen sparen kann, und das ist alles auf dem CCD. Dann hat die 3D-Variante moeglicherweise sogar einen Kostenvorteil gegenueber einem CCD mit 96MB cache (wo man zusaetzliche Leitungen und damit Flaeche braucht).
 
Ich hoffe AMD erbarmt sich und bringt auch einen 6 oder 8 Core mit min. 128 MB Cache für AM4.

Für 3xxx Besitzer und kleiner wäre das ein Hammerupgrade, 5xxx eh schon mit ~20% mehr Leistung dazu nochmal 15 - 20% durch den Cache.
 
  • Gefällt mir
Reaktionen: konkretor
[wege]mini schrieb:
Beim P4 EE bin ich mir nicht sicher. Sind das umbenannte Xeons?

Wenn ich mich nicht irre, waren die ersten Pentium 4 Extreme Edition im Prinzip Xeon MPs mit 2MB L3-Cache, aber für den Consumer-Sockel 478. Also nicht reine Umbenennungen (wie bei AMDs frühen FX, die z.B. sogar teuren Server-Speicher brauchten), aber technisch doch klar aus der Server-Seite.
 
  • Gefällt mir
Reaktionen: konkretor und [wege]mini
Hat Intel mit Broadwell damals ja schon gut vorgezeigt was in Games möglich wäre.
Falls AMD das mehr an Cache nur in den 2 Topmodellen bringt, werden diese natürlich für Gamer, wenn der Preis passt durchaus interessant.
Aber rund 15% mehr Leistung in Games wäre auch schon beachtlich, nur durch den Cache.
 
Herdware schrieb:
aber technisch doch klar aus der Server-Seite.

Jo, hat Konkretor auch schon erklärt und da ich gerne Wissenslücken schließe (auch wenn es unnützes Wissen ist) habe ich selber auch schon recherchiert.

Auf der (un)möglichen MP Tauglichkeit rumzureiten, ergibt ja dann gar keinen Sinn mehr und technisch sind sie Xeons.

mfg
 
Balikon schrieb:
Wenn ich meine Aussage auf Consumer beschränke, trifft sie eher zu, oder?

Ich kenne mich ehrlich gesagt nicht genug aus, um zu sagen, welche Consumer-Anwendungen abseits von Spielen von großem Cache profitieren. Typischem Kleinkram wie Office und Browser ist es wahrscheinlich realtiv egal und ich vermute, z.B. bei sowas wie Video-De-/Encoding hilft Cache auch nur begrenzt.

Die grundsätzliche Aussage, dass großer Cache für Consumer vor allem für Spiele relevant ist, dürfte stimmen.
 
  • Gefällt mir
Reaktionen: latiose88, Balikon und [wege]mini
ETI1120 schrieb:
Durch beide Konfigurationen lässt man die Benchmarks durchrauschen die einen selbst interessieren.
Der Unterschied entspricht der IPC-Steigerung.
Die IPC Steigerungen die Intel und AMD in ihren Marketing Slides angeben ( xx% higher IPC than competition ) sind reiner Marketing Fluff. Das hat noch nicht mal ansatzweise was mit IPC zu tun. Man vergleicht eigentlich die Leistung des Gesamtsystems für bestimmte Workloads. Das ist auch ok und durchaus nützlich, aber hat mit IPC nun gar nichts zu tun.

ETI1120 schrieb:
Eine absolute Zahl wird es für IPC nie geben, da das absolute Ergebnis von unzähligen Parametern abhängt. Mips wurde schon in den 90ern des letzten Jahrhunderts begraben. Es war nicht aussagekräftig.
Unter CPU Architekten wird DMIPS/Mhz oder Coremark/Mhz immer noch gerne verwendet. Steht auch in den offiziellen Datenblättern von ARM.
Wenn man die IPC der Pipeline messen möchte, sind Benchmarks die komplett in den L1 Caches ablaufen, durchaus nützlich. Leider ist speziell DMIPS so extrem vom Compiler und der C Runtime abhängig, das er enorme Ungenauigkeiten aufweist.
Ausserdem berücksichtigt er nur Integerleistung, kein FP, kein SIMD. Am Ende ist es auch wieder eine Marketing Zahl…
ETI1120 schrieb:
Specmark wird für PCs kaum noch verwendet, da die darin verwendete Benchmarks für PC-Anwender wenig Relevanz haben
Für PC nicht, aber für die CPUs schon. Intel und AMD veröffentlichten schon Specmark Werte, im HPC Bereich sind die auch wichtig.

Benchmarks sind immer abhängig von der Zielgruppe, es gibt auch spezielle Benchmarks für Datenbanken, Webserver oder auch SAP Systeme.

0x8100 schrieb:
früher™ brauchte man den tag-ram, damit der ram überhaupt cachable war und man musste dafür sorgen, dass dieser zur grösse des rams passte
Auch heute haben die Caches noch tag RAMs, der ist natürlich zusammen mit den Cachelines auf dem Die integriert. Ohne tag funktioniert ein Cache nicht, irgendwo muss er ja speichern welche Adresse er nun gerade in einer Cacheline zugeordnet ist
 
TomH22 schrieb:
irgendwo muss er ja speichern welche Adresse er nun gerade in einer Cacheline zugeordnet ist

Das versteht sich ja von selbst und das muss nicht noch 1000mal wiederholt werden. Die Frage ist doch, wie groß ist er? Nicht in mm² sondern in Bit.

Er wird ja nicht genauso groß sein, wie der Cache selber?

Dieser ist in mm² sogar ziemlich klein (6x6 mm) und wenn man jetzt auf den 32MB Cache, noch einmal 64MB draufstapelt, bleibt die Fläche sogar gleich :D

"Da der 3D V-Cache über den bisherigen L3-Cache gesetzt wird und dieser nicht der Hotspot der CPU ist"

mfg
 
  • Gefällt mir
Reaktionen: jemandanders
Zurück
Oben