DDR4-Standard soll noch 2012 verabschiedet werden

DDRX ist ein Standard zur Ansprechung von Speichermodulen und macht keine Aussage über deren Funktionsweise. Wenn die Speicherhersteller, die an entsprechenden Techniken arbeiten, schlau sind, dann setzen sie in den Specs gleich die Möglichkeit eines unendlichen Refreshintervalls und Verschmelzung von S3 und S4 durch und schon ist DDR4 die ideale Grundlage für z.B. MR-RAM-Chips mit passendem Controller.
Afaik sind die Entwickler aber noch meilenweit davon entfernt, Memristoren mit DRAM-Geschwindigkeit zu fertigen, von Serienreife mal ganz abgesehen. Wenn 2014 Massenspeicher auf der Basis verfügbar sind, wäre das schon ne gute Leistung.

Naja, es gibt ja noch mehr als Memristor

In Labors ja - in freier Wildbahn nicht. Irgendwie findet man schneller "sensationelle" Technologien, als man die alten serienreif hat. (was schade ist. Ich hatte mich schon auf den Streit zwischen Raytheon und IBM wegen ähnlich klingenden Produktbezeichnung gefreut, wenn letztere eine "advanced" Version von MRA(A)M auf den Markt bringen )

Naja, die Jungs in den Firmen sind schon groß am Entwickeln

Da sollte man einfach etwas Geduld haben. Wenn man aber bedenkt, wie wenig sich in den letzten 40 Jahren beim RAM getan hat, stehen aktuell wirklich VIELE Technologien in den Startlöchern, die alle ihren Einsatzbereich finden könnten.

Angefangen von schneller als DRAM aber weniger Kapazität bis hin zu langsamer, aber dafür deutlich mehr Kapazität. Da muss man dann natürlich auch schauen, ob man die neuen Technologien nicht irgendwie kombinieren kann, und was Sie bringen. 10% mehr Leistung bei 100% Mehrkosten zahlt dir halt eigentlich keiner. Bei 10% weniger Leistung und 50% weniger Kosten, wird die Sache dagegen unter Umständen schon wieder verdammt interessant

Oder was würdest du zu ner SSD sagen, die 10% weniger Leistung hat als die heutigen Topmodelle, dafür aber nur 50% kostet?

Also zumindest ich glaube, dass das ein echter Kassenschlager wäre

Beim RAM wird sich in den nächsten Jahren definitiv etwas tun (auch tun müssen!!! Die Lücke zwischen Speicherinterface bzw. I/O allgemein und CPU-Leistung geht immer weiter auseinander, und das schon seit Jahrzehnten. Gibt dazu ja auch eine Version von Moorse law)

Ich hoffe ja, das wir endlich mal wieder Slot CPUs sehen, oder so, wo man extra SRAM/DRAM (whot ever) als zusätzliche Module auf den CPU-Träger mit aufgebracht hat, so wie es ne Zeit lang bei AMD und Intel mit dem L2 Cache war. Wahrscheinlicher ist aber, dass die Sache per stacked chips "direkt" in der CPU umgesetzt wird. Die Anbindung der Datenleitungen ist da einfach VIEL einfacher.

Folgendes Gedankenmodell klingt doch verlockend oder?

10 lagen Chip:
Auf den Lagen 8-10 pro Lage 2 Cores + 128 kBit L1 + 4 MB L2
Auf den Lagen 6+7 jeweils 8 MB L3 Cache
Auf den Lagen 2-5 jeweils 1 Core + 128kBit L1 + 4MB L2 + Durchführungen für die direkte Verbindung zwischen Lage 1 und Lagen 6+7
Auf der Lage 1 dann komplett I/O


Die Zahlen sind natürlich nur aus der Luft gegriffen, aber vom Konzept her sicherlich sehr interessant. Das Problem ist halt die dritte Dimension, die man erst mal was das Design betrifft begreifen muss. Wie viele Wires kann ich zwischen den Lagen machen etc. etc. etc.

Btw. das Erinnert mich verdammt stark an das Problem von riesigen Gebäuden, wo man Konzepte entwickeln muss, wie man die Leute per Aufzug ins Haus und wieder raus bekommt. Expressuafzüge, Doppestockaufzüge etc. sind da ja alles Konzepte, da man mit normalem Vorgehen die gesamte Grundfläche ja mit Aufzügen zuballern würde

Das Problem ist vor allem, dass du auf der Fläche eines Dualcore einen Hexacore kühlen musst...
Ganz abgesehen davon, dass ein Kern eine viel zu breite Anbindung braucht. Wenn du vier Stück davon durch den Stack anbietest, hast du untern nur noch Löcher, aber keine Nutzfläche mehr.
Vorerst würde ich bei CPUs gar nicht mit stacked Chips rechnen. Die Größe der Substrate wird schon seit Ewigkeiten von den benötigten Kontakten im Sockel bestimmt, wenn man wollte könnte man längst doppelt oder dreimal soviel Silizium nebeneinander verbauen - ohne davon die Hälfte für Löcher zu opfern. Alternativ könnte man den L2 ohne TSV einfach on Top packen, schließlich ist der ohnehin CPU-intern angebunden. Macht man aber auch nicht, weil es die Fertigungskosten und der Verbrauch sind, die die Chipgröße bestimmen.

Aber mir RAM hat das alles wenig zu tun. Da liegen die Probleme gnadenlos bei den Latenzen und die kann man nur verbessern, in dem man die Speicherzellen massiv beschleunigt. Aber da ist afaik gar keine Technik in der Mache, die wirklich schneller ist - die einzige Option wäre, dass mit weiter fortschreitender Technik SRAM in den Bereich des finanzierbaren rückt. Aber sinnvoll wäre das auch größtenteils nur für Heimanwender (bei denen die meisten Anwendungen einfach Speichergeschwindigkeit und nicht -größe abhängig sind) und für die führt man nichts extra teures ein, weil mans eh nicht vermarktet bekommt.

Also: Abwarten. Bei Massenspeichern ist viel zu tun und es gibt viel interessantes (auch wenns alles noch reifen muss...), aber bei RAM mache ich mir keine großen Hoffnungen.

Nene Ruyven, bei Serveranwendungen bist du sehr oft schlicht I/O Limitiert. SRAM, auch wenn es nur 500 MB oder so sind, würde da extrem viel reißen. Und wie ich schon mal in nem anderen Topic erzählt habe, Kühlung ist kein Problem mehr. I/O Limitierung noch etwas, dank Optic-onDIE kann das aber durchaus sich noch ändern.

Und zu den Sachen mit den Vias und Cores. Soooo viele brauchst du da jetzt auch nicht bei dem vorgeschlagenen Aufbau Eigentlich nur den L3 anbinden, und man ist glücklich. Ok ok, pack noch nen paar Leitungen für snooping wegen der Cache-Kohärenz ein, aber das wars dann auch schon. Sooo viel ist das gar nicht.

Da ist eher die Stromversorgung kritisch zu sehen. Son Ding würde nämlich sicherlich 200W+ schlucken

Aber um mal wieder den Bogen zu bekommen, warum das durchaus interessant ist.

Man hat ja bei jedem Programm gewisse Regionen, in denen das Programm ne ganze Zeit abläuft, bevor es diese verlässt und in der nächsten weiter arbeitet. Wenn man das alles in die Caches bekommt, ist man massiv schneller, als wenn es in den RAM oder gar die HDD/SSD mit rein fällt. Es ist daher auch gar nicht uninteressant, etwas mehr schnelleren Speicher (SRAM z.B.) zu haben, der halt teuer ist, und dafür den normalen DRAM mit etwas langsameren aber billigeren zu ersetzen, der vielleicht sogar noch mehr Kapazität hat. Hab dazu ein ganz interessantes Paper gelesen. War wirklich sehr interessant.

Skysnake schrieb:

Nene Ruyven, bei Serveranwendungen bist du sehr oft schlicht I/O Limitiert. SRAM, auch wenn es nur 500 MB oder so sind, würde da extrem viel reißen.

Zum Vergrößern anklicken....

Wir reden hier nicht von zusätzlichen Lösungen (etwas zusätzlich einzuführen, ist noch schwerer), wir reden hier von Speicherstandards, die alte ersetzen. Und ich denke, soviel verstehe ich gerade noch von Servern, um zu erkennen, dass eine Reduktion der Speichergröße auf ~1/8tel (oder gar 500 MB...) eine Katastrophe wäre, auch wenn es SRAM ist. Du selbst wirst in anderen Threads nicht müde, darauf hinzuweisen, welch wichtiger Vorteil der maximale Speicherausbau für einige AMD-Plattformen ist.
Sowas könnte man sich somit nur im Heimanwenderbereich erlauben, wo bis heute kaum mehr als 2-3 GB genutzt werden, aber 16-24 GB problemlos und das doppelte prinzipiell verbaut werden könnten.

Und zu den Sachen mit den Vias und Cores. Soooo viele brauchst du da jetzt auch nicht bei dem vorgeschlagenen Aufbau Eigentlich nur den L3 anbinden, und man ist glücklich.

Zum Vergrößern anklicken....

Ich persönlich wäre nicht Glücklich, wenn nur der Cache an den I/O-Bereich angebunden ist, aber die Kerne nicht - aber wie du meinst.

Da ist eher die Stromversorgung kritisch zu sehen. Son Ding würde nämlich sicherlich 200W+ schlucken

Zum Vergrößern anklicken....

Die wiederum lässt sich, je nach deinen Anforderungen an Sleepmodes (und wieso sollte jeder Kern einzeln ausschaltbar sein?), sehr leicht realisieren, weil du für eine Kern-Ebene nur einmal Masse und einmal Strom brauchst und die kannst du über die Kanten auf sehr großem Querschnitt liefern.

ruyven_macaran schrieb:

Wir reden hier nicht von zusätzlichen Lösungen (etwas zusätzlich einzuführen, ist noch schwerer), wir reden hier von Speicherstandards, die alte ersetzen. Und ich denke, soviel verstehe ich gerade noch von Servern, um zu erkennen, dass eine Reduktion der Speichergröße auf ~1/8tel (oder gar 500 MB...) eine Katastrophe wäre, auch wenn es SRAM ist. Du selbst wirst in anderen Threads nicht müde, darauf hinzuweisen, welch wichtiger Vorteil der maximale Speicherausbau für einige AMD-Plattformen ist.
Sowas könnte man sich somit nur im Heimanwenderbereich erlauben, wo bis heute kaum mehr als 2-3 GB genutzt werden, aber 16-24 GB problemlos und das doppelte prinzipiell verbaut werden könnten.

Zum Vergrößern anklicken....

Der SRAM soll ja auch nur ein Cache sein, der richtig fix ist. Dahinter kommen dann natürlich einige GB an "RAM". Aber halt langsamer als DRAM, aber noch immer deutlich schneller als ne SSD.

Von der Leistung her wäre ja alles "einfach" in SRAM zu machen optimal, aber das wäre ja nicht zu bezahlen, da die Datendichte viel kleiner ist. Wenn man aber z.B. 32GB für den gleichen Preis bekommt, wie 8 GB DRAM, dann kann man auch einfach 16 GB vom neuen etwas langsameren RAM nehmen, und den Rest des Geldes in einen SRAM-Cache stecken, der eben vorzugsweise direkt neben der CPU sitzt. Weist du jetzt, was ich meine?

PS: Ich hab mal meinen Post nochmals gelesen, das war glaub ich nicht wirklich klar erkennbar, dass ich meinte, dass man den eigentlichen "RAM" eben Cached, weil man etwas langsameres als DRAM nutzt, das aber eine höhere Speicherdichte hat. Ich hab dir mal nen Link geschickt, ich glaub dann verstehst du besser, was ich meine.

Ich persönlich wäre nicht Glücklich, wenn nur der Cache an den I/O-Bereich angebunden ist, aber die Kerne nicht - aber wie du meinst.

Zum Vergrößern anklicken....

Wie/Wieso willst du die Cores an den I/O anbinden? Macht doch nicht wirklich Sinn. Ok, fürs lesen wäre ein Beipass nett, damit man nicht durch die Cache-Stufen propagieren muss, aber gerade fürs schreiben ist es halt absolut unsinnig. Packst halt noch paar Leiterbahnen dazu um den L1 mit dem RAM-Controller zu verbinden, mehr brauchst du aber nicht. Warum auch?

Die wiederum lässt sich, je nach deinen Anforderungen an Sleepmodes (und wieso sollte jeder Kern einzeln ausschaltbar sein?), sehr leicht realisieren, weil du für eine Kern-Ebene nur einmal Masse und einmal Strom brauchst und die kannst du über die Kanten auf sehr großem Querschnitt liefern.

Zum Vergrößern anklicken....

Ruyven, und warum haben wir nicht an den heutigen CPU die dicken Streifen?

So einfach ist die Spannungsversorgung der CPU nicht. Klar, du könntest so genug Saft durch die CPU pressen, aber du vergisst den Spannungsabfall. Deswegen brauchst du ja eine Vielzahl von Einspeisepunkten für die Spannung, und dazu dann noch "kleine" Kondis, um die Spannung auf dem Chip zu stabilisieren. So einfach ist die Sache leider nicht, auch wenn das wirklich sehr cool wäre, wenn es gehen würde

Skysnake schrieb:

Weist du jetzt, was ich meine?

Zum Vergrößern anklicken....

Ich weiß, was du meinst - deswegen habe ich auch schon geantwortet, als ich darauf hingewiesen habe, dass du eine Technik, die erfordert, dass CPU und Speicherhersteller eine komplette zusätzliche Schnittstelle schaffen, so schnell nicht sehen wirst.

Wie/Wieso willst du die Cores an den I/O anbinden? Macht doch nicht wirklich Sinn. Ok, fürs lesen wäre ein Beipass nett, damit man nicht durch die Cache-Stufen propagieren muss, aber gerade fürs schreiben ist es halt absolut unsinnig. Packst halt noch paar Leiterbahnen dazu um den L1 mit dem RAM-Controller zu verbinden, mehr brauchst du aber nicht. Warum auch?

Zum Vergrößern anklicken....

Ich bin kein CPU-Entwickler, ich stelle nur fest, dass sämtliche Layouts, die so präsentiert werden, die CPU nicht über den Cache anbinden. Der letzte Chip, der mir einfällt, bei dem die Kommunikation zwischen CPU und Cache über die gleichen Leitungen lief, wie die Kommunikation zwischen CPU und restlichem System, war der Pentium 1.

Ruyven, und warum haben wir nicht an den heutigen CPU die dicken Streifen?

Zum Vergrößern anklicken....

Weil unsere heutigen CPUs -im Gegensatz zu achtfach-Stacks- recht viele Fläche/Recheneinheit, aber recht wenig Kante haben und es außerdem viel einfacher ist, ein DIE einfach flächig auf Kontaktflächen anzubinden, als es nach der Montage auf dem Substrat zusätzlich großflächig an der Seite zu kontakten?

So einfach ist die Spannungsversorgung der CPU nicht. Klar, du könntest so genug Saft durch die CPU pressen, aber du vergisst den Spannungsabfall. Deswegen brauchst du ja eine Vielzahl von Einspeisepunkten für die Spannung, und dazu dann noch "kleine" Kondis, um die Spannung auf dem Chip zu stabilisieren. So einfach ist die Sache leider nicht, auch wenn das wirklich sehr cool wäre, wenn es gehen würde

Zum Vergrößern anklicken....

Wäre mir ziemlich neu, dass es Kondesatoren gibt, die Spannungen zwischen einzelnen Bereichen des DIEs zwischenpuffern.
Und natürlich ist es billiger, die Spannung im Substrat zu verteilen und an mehreren Punkten einzuspeisen, als dicke Leitungen quer durchs Silizium zu ziehen. Aber wenn die Wahl nicht mehr "Substrat vs. Leitungen auf Silizium", sondern "Leitungen auf einer Siliziumebene vs. Löcher in allen Siliziumebenen" lautet, sieht die Sache anders aus.


Aber wie schon erwähnt: Die Lösbarkeit der technischen Probleme ist eigentlich wurscht, solange die hohen Kosten bleiben und der Platz eh vorhanden ist. Auf der Fläche eines So2011 Packages sollten sich eigentlich 9 DIEs von der Größe eines Sandy Bridge unterbringen lassen. Die muss man erstmal mit Inhalten füllen, die ihr Geld auch wert sind - dann kann man darüber nachdenken, wie man Silizium verschwendet und Kühlprobelme schafft, um noch mehr Transistoren zu nutzen.

Ja, die Kondis gibts wirklich, weil die Spannung sonst nicht stabil genug wäre. Da wird ein ziemlicher Aufwand betrieben.

Ähm, ich glaub wir reden grad aneinander vorbei, was die "Kommunikation" anbelangt. Meinst du, das ich denke, dass man rein mit Load/Stores arbeitet??? So kommts mir zumindest gerade vor.

Die Interconnects für Cache-Snooping für die Cohärenz etc. musst du natürlich bereit halten, genau wie die Leitungen zur MMU, dem DMA und für die Interrupts. Das sind aber nur recht wenige, wenn man jetzt mal im Gegensatz dazu die Anbindung der Caches untereinander (bzw. richtiger, da muss ich dir Recht geben, zwischen Cores und den gemeinsam genutzen Caches, was in meinem BSP ja nur der L3 sein sollte, und damit eigentlich passen sollte. laut meiner Beschreibung oder?). L2->L3 wäre ja trivial, und L2->L2 muss man nicht verbinden, und die paar Leitungen für die Cachekohärenz hab ich jetzt wirklich unterschlagen. Das sollte wirklich nicht ins Gewicht fallen, was die Anzahl der Leitungen anbetrifft, die durchs Silizium geführt werden müssen.

Oder was fällt dir sonst noch spontan an Anbindungen ein, die ich übersehen habe?

Mit Ausnahme von "Cache" finde ich bei dir nur eine lange Liste von Steuerungsleitungen. Was ich weiterhin vermisse sind die Datenleitungen zwischen Kern und Northbridge, denn wie erwähnt: Man greift nicht über den Cache aufs Restsystem zu, das geht direkt.
Es sei denn, du willst das alles über einen Ringbus laufen lassen, wie bei Sandy Bridge. Der hat aber auch immerhin 256 Bit Breite und arbeitet in zwei Richtungen, d.h. du hast 1024 Kontaktstellen allein für den Datenverkehr von Layer zu Layer - wenn du Kerne und Cache gleichmäßig verteilst. Wolltest du aber nicht, sondern den Cache separat platzieren. Ergäbe bei dir also z.B. zwischen Lage 7 und 8 1024 Kontakte für den Ringbus und sechs weitere afaik 256 Bit Verbindungen von den Ringknoten der höherliegenden Kerne - immerhin 8192 Kontakte, die durch das Silizium der achten Schicht müssen. Dazu kommt dann deine lange Liste an Nebenkriegsschauplätzen und die Stromversorgung.

Ich meld mich dazu mal die Tage nochmal. Seh jetzt grad nicht, warum du auf 8k kommst so schnell.

Erinnere mich ruhig nächste Woche nochmal dran.

:/ hab mich da um eine Potenz vertan. Wären "nur" 4096:
256 Bit Ring Interface = 2 Richtungen a 256 Bit a 2 Adern = 1024 Kontakte für den Ringbus.
Wenn die L3-Chunks nicht auf der gleichen Ebene liegen, wie die Kerne, kommen die Verbindungen vom Ringbus-Knoten/Kern zum L3-Chunk dazu. Ich gehe hier ebenfalls von 256 Bit = 512 Kontakte pro Kern. Du siehst zusammen 6 Kerne auf den Ebenen 8, 9 und 10 vor. Macht 3072 Kontakte für die Kern-Cache Verbindungen, zusätzlich zu den 1024 => 4096.

Ich hab leider keine Informationen finden können, wieviel Platz ein Via belegt (angegeben werden nur die Leitungsdurchmesser, die natürlich sehr klein sind - aber ich vermute mal, dass drumherum viele Platz gelassen werden muss, damit die Kontakte zielsicher und ohne Kurzschlüsse angebunden werden können)

Um die VIAs sollte eigentlich nicht sonderlich viel Platz frei bleiben müssen. Die passen ja entweder alle, oder eben alle nicht. Tolleranzen sind da winzig. Halt < Strukturgröße, oder maximal das doppelte, weil man ja doch etwas mehr machen muss. Was die Sache halt relativ "leicht" macht ist die, das man nur in 2 D die Sache positionieren muss. Verdammt eben sind die Wafer ja

Zu den Breiten. Waren das nicht eher 128 Bit breite Anbindungen?

Muss mal nach dem Umzug das Skript vom letzten Jahr raus kruscheln, da sollte das für einige Architekturen aufgeführt sein.

Also ich hab nix gegen Neuen Ram immer schön her mit Ram wird ja immer mehr Gefressen von den Ganzen Programmen ^^

Ich haette ja fruehestens 2013 damit gerechnet... aber es geht ja nur um ein "Verabschieden des Standards"

Leider hoert man nichts mehr davon, dass anstelle der Channels jedes Modul einzeln angesprochen werden soll, sodass man jedes RAM Modul mit seiner vollen Bandbreite ansprechen kann

Das er schon im Bulldozer II zum Einsatz kommt halte ich fuer fast ausgeschlossen- es ist einfach noch zu frueh und AMD war hier nie ein Vorreiter

Schade finde ich auch, dass niemand ueber Rambus nachdenkt; was man von XDR2 hoert ist schon beeindruckend

RAMBUS verschlimmert den entscheidenden Problempunkt (Latenz), kostet mehr und der einzige Vorteil liegt in einem Bereich (Bandbreite), in dem kein Bedarf besteht.

Bezüglich Modul/Kanal:
Du kannst an einem Speicherkanal nur einen Speicherkanal nutzen. Die Möglichkeit zur Nutzung mehrerer Module pro Kanal abzuschaffen, wäre einfach nur ein riesen Rückschritt in Sachen Speicherausbau.

RAMBUS verschlimmert den entscheidenden Problempunkt (Latenz), kostet mehr und der einzige Vorteil liegt in einem Bereich (Bandbreite), in dem kein Bedarf besteht.

Zum Vergrößern anklicken....

Über die Latenzen von XDR(2) weiß ich nichts- aber wenn du recht hast und sie (noch) schlechter sind ist das natürlich ein großer Nachteil

Das er teurer sein müsste denke ich nicht; das XDR aktuell so teuer ist liegt an den geringen Stückzahlen (vor allem im Vergleich zu DDR2/3) und die hohen RAMBUS Preise zu P4 Zeiten waren einem Speicherkartell zu verdanken

Bezüglich Modul/Kanal:
Du kannst an einem Speicherkanal nur einen Speicherkanal nutzen. Die Möglichkeit zur Nutzung mehrerer Module pro Kanal abzuschaffen, wäre einfach nur ein riesen Rückschritt in Sachen Speicherausbau.

Zum Vergrößern anklicken....

Ursprüngliche Ideen scheinen ja gewesen zu sein, dass ein Speichercontroller immer jedes Modul einzeln ansprechen kann, sprich: quad oder hexachannel auf Desktopplattformen, auf Servern vielleicht auch mehr, eben so viel, wie in der Praxis für die jeweilige Plattform in Frage kommt

Superwip schrieb:

Über die Latenzen von XDR(2) weiß ich nichts- aber wenn du recht hast und sie (noch) schlechter sind ist das natürlich ein großer Nachteil

Das er teurer sein müsste denke ich nicht; das XDR aktuell so teuer ist liegt an den geringen Stückzahlen (vor allem im Vergleich zu DDR2/3) und die hohen RAMBUS Preise zu P4 Zeiten waren einem Speicherkartell zu verdanken

Zum Vergrößern anklicken....

RAMBUS ist einfach aufwendiger. Das bringt höhere Kosten für die Chips mit sich, die man beim Board nicht wirklich wieder reinbekommt und es bringt höhere Latenzen mit sich. DRAM bleibt nunmal DRAM und wenn man die Speicherzellen mit weniger Leitungen anbinden und trotzdem eine höhere Bandbreite erzielen will, dann macht sich das bemerkbar.

Ursprüngliche Ideen scheinen ja gewesen zu sein, dass ein Speichercontroller immer jedes Modul einzeln ansprechen kann, sprich: quad oder hexachannel auf Desktopplattformen, auf Servern vielleicht auch mehr, eben so viel, wie in der Praxis für die jeweilige Plattform in Frage kommt

Zum Vergrößern anklicken....

Aber genau diese Idee ist (außer mit RAMBUS ) praktisch nicht realisierbar, weil du viel zu viele Leitungen brauchst. Und es macht auch nicht wirklich Sinn, sie zu realisieren, weil die CPUs diese gigantische Bandbreite gar nicht gebrauchen können.

Bin ja gespannt was die Module dann kosten werden.

Wie war es damals beim Release von DDR3, waren die wesentlich teuerer als DDR2, bin da nicht so informiert.