News UltraRAM: RAM-Massenspeicher-Symbiose rückt Serie näher

mkossmann schrieb:
Ob das als DRAM-Ersatz für einen PC wirklich reicht ?
Karre schrieb:
wenn der Rentner dem Junior das Fürchten beibringt:
FD1B5B26-74E9-49E5-A8D6-A81EF6E9E833.jpeg


Meine Samsung SSD liegt bei ca. 3.000 MB/s.
Der Core 2 Quad, auf dem Windows 11 läuft, hat theoretisch 10,4 GB/s.
Für Windows reicht es vollkommen, für mehr muss man sehen, ob wirklich 50 GB/s reichen (sie sprechen ja nur von DRAM ähnlichen Übertragungsraten).
Ergänzung ()

Raziel-Noir schrieb:
Als eine keine RamDisk, sondern eher DiskRam
Müsste ich mal auf meinem Oppo testen (wie auch immer), da es ja 4GB + 1GB RAM nutzt. Da läuft ja schon ein Teil auf dem Festspeicher.
 
bad_sign schrieb:


Ich weiß jetzt nicht genau wie der Beitrag gemeint ist.

Sie haben es geschafft das ganze auf einem Silikon Wafer zu demonstrieren und bezeichnen es als einen wichtigen Schritt auf dem Weg zur Massenfertigung.
Passt doch so meiner Meinung nach

Wäre so ein Titel "Triple-Barrier-Resonant-Tunneling-Strukturen auf SI Substrat könnte die kommerzielle Produktion von nicht flüchtigen Speichermodules auf Basis von Indiumarsenid und Aluminiumantimonid ermöglichen"?
 
sikarr schrieb:
Da wird nix langsamer, wen der voll ist, ist Ende im Gelände. Heute kann der PC ja auf die Auslagerungsdatei (Windows) bzw. SWAP Partition (Unix/Linux) zurückgreifen, die wirds da nicht mehr geben ;)

Schon klar. Ich präzisiere: Ziemlich voll ist.
Ergänzung ()

cloudman schrieb:
Ich weiß jetzt nicht genau wie der Beitrag gemeint ist.

"Die Uni ist ein hässliches Gebäude
Mit noch hässlicheren Räumen
Voll Studenten, die sich freuen"
 
  • Gefällt mir
Reaktionen: sikarr
andi_sco schrieb:
Für Windows reicht es vollkommen, für mehr muss man sehen, ob wirklich 50 GB/s reichen (sie sprechen ja nur von DRAM ähnlichen Übertragungsraten).
Du darfst dabei aber die Zugriffszeiten nicht vergessen, die sind bei DRAM deutlich schneller als bei NAND ns vs ms, da nützt dir dann die hohe Übertragungsgeschwindigkeit auch nichts mehr.
 
Fände ich aus Datenschutzgründen nicht gut, da dann anders als bei DRAM vermutlich einmal geschriebene Bits wieder hergestellt werden könnten.
 
Habe solche oder ähnliche Berichte schon vor Jahren gelesen. Nicht,dass ich etwas dagegen hätte, ich erwarte nur erst einmal wenig.
 
mae schrieb:
Da musstest du nach dem auslesen aber die Zelle wieder neu beschreiben, weil die Information danach gelöscht war
 
  • Gefällt mir
Reaktionen: rg88
Klingt ja fast wie ein Wunder der Speicher. Es muss wohl Zauberei sein. 🙂
 
Nur um es mal ins Verhältnis zu setzen. Die endurance von DRAM liegt bei min >10^10. Also Faktor 1000 höher als vom SuperRAM wenn man also die gleiche Endurance haben will wie mit RAM muss man also GB durch TB ersetzen. Ubd wieviel GB hat so ein System heute? Ah ja, 16-32GB.

Also mal schwuppig 16-32TB an Speicheer ins System klatschen. Für Consumer könnte das dann vielleicht sogar ausgehen mit der Haltbarkeit. Das Problem ist nur, man findet sich Angaben von >10^15 für die DRAM Endurance. Und da bist du dann in völlig unrealistischen Bereichen für den Speicher hier.

Und ja, in Servern ballerst du halt schon teils auf 128GB RAM mit durchgehend 256GB/s. Ok nehmen wir R:W von 50:50 an, schreibt man trotzdem jede Sekunde seinen Speicher voll. Der Speicher hier wäre also nach 10^10-15s durch. Also maximal nach 116 Tagen. Nutzungsdauer liegt so bei 5 Jahren. Also 1826 Tagen. Geteilt durch 116 Tage macht Faktor 15.7 mehr Kapazität die man braucht. Um den Betrag muss natürlich dann auch der Speicher billiger werden. Ansonsten macht das absolut keinen Sinn als DRAM Ersatz.

Klar jetzt kommt das Argument, das man nicht mehr so viel mehrfach berechnen muss weil einem der RAM ausgeht. Ok, aber man will/braucht ja auch Puffer weil man nicht gleichmäßig schreibt. Und die 10^10 sind ja tief gestapelt. Man will ja auch nicht in den realistischen Bereich der Endurance kommen.

Also pack nochmals Faktor 10-100 drauf. Der neue Speicher muss also bei ansonsten gleichen Werten Faktor 150-1500 billiger sein um wenigstens eine Option zu sein...
 
  • Gefällt mir
Reaktionen: rg88
Schon lustig. Ist gerade mal ein Prototyp und schon werden hier die Rechnungen aufgestellt.
Was sollen die eurer Meinung nach machen? Auf hören zu forschen weil ein Prototyp noch nicht reif für den Massenmarkt ist?
 
  • Gefällt mir
Reaktionen: andi_sco und Colindo
Limeray schrieb:
Schon lustig. Ist gerade mal ein Prototyp und schon werden hier die Rechnungen aufgestellt.
Wo ist denn das Problem? Ist es in deiner Welt verboten, dass man Sachen hinterfragt und auf Machbarkeit hin überprüft?
Denkverbote sind nicht sehr wissenschaftlich.

Limeray schrieb:
Auf hören zu forschen weil ein Prototyp noch nicht reif für den Massenmarkt ist?
Der einzige der das sagt, bist eigentlich du hier....

Limeray schrieb:
Was sollen die eurer Meinung nach machen?
Du darfst gerne mitdiskutieren und deine Meinung kundtun und auch andere Überlegungen widerlegen.
Aber rumstänkern und solche Art von Fragen bringt hier sicherlich niemanden weiter
 
Es realistisch Einschätzen?

Das Zeug klingt super als Flash Ersatz.
 
  • Gefällt mir
Reaktionen: nitech und rg88
Skysnake schrieb:
Das Zeug klingt super als Flash Ersatz.
Jepp.
Ich verstehe deshalb nicht, warum man als Forscher hier bei Grundlagenforschung bereits Produkte und Anwendungsfälle mit anpreist, wenn diese total unrealistisch sind. Damit entfacht man genau diese Diskussionen die wir jetzt hier führen und das ganze hat so einen Geschmack von Wunder... und das das in aller Regel dann doch nicht eintritt, ist das halt mehr ein Eigentor
 
  • Gefällt mir
Reaktionen: bad_sign und Skysnake
rg88 schrieb:
es macht überhaupt keinen Sinn. Im VRAM liegen Texturen und Zwischenergebnisse der GPU. Die Ergebnisse der GPU sind nach der Bildausgabe obsolet und die Texturen würden eh nicht alle in den Speicher passen. Oder soll der Wunderspeicher 20TB groß sein um alle entpackten Texturen von 10 Spielen bereit zu halten?

Eventuell muss man die Texturen gar nicht entpackt ablegen?

Bin kein Experte und kann das eher schlecht auf diese Situation übertragen, aber ZFS schafft es quasi verzögerungsfrei gepackte Daten bei Gebrauch "on the fly" zu entpacken.
Keine Ahnung wie das bei Daten gepackt im UltraRAM -> entpackt im Cache aussehen würde, sind dann doch nochmal gaaaanz andere Geschwindigkeiten.

Oder man geht tatsächlich in die Richtung mehr Speicher, wobei 20TB für einen Festspeicher jetzt nicht die Welt sind, aber scheinbar ja gerade für die Texturen von 10 Spielen reichen würde.

Vielleicht auch eine Mischung einen einfachen Kompressionsalgorithmus, den man schnell genug entpacken kann.
 
TrueAzrael schrieb:
aber ZFS schafft es quasi verzögerungsfrei gepackte Daten bei Gebrauch "on the fly" zu entpacken.
und wer macht die Berechnung? Entpacken ist eine aufwändige Rechenoperation. Soll das die GPU noch nebenbei mitmachen?

TrueAzrael schrieb:
Vielleicht auch eine Mischung einen einfachen Kompressionsalgorithmus, den man schnell genug entpacken kann.
Die nächste Quadratur des Kreises ;)

TrueAzrael schrieb:
Eventuell muss man die Texturen gar nicht entpackt ablegen?
Gepackte Daten sind nutzlose Daten. Könnte man sie direkt ohne entpacken benutzen, müsste man sie ja im Grunde gar nicht packen, dann wär das ja das eigentliche Datenformat ;)
 
Ich weiß gar nicht, ob ich das so toll fänden wenn das tatsächlich so verwendet werden würde. Aufgrund des ganzen Sicherheitschaos wird langsam ja eher der Ruf nach mehr statt weniger Trennung laut. Manch einer würde vermutlich lieber voll auf Harvard-Architektur umstellen als RAM und Storage zu kombinieren.
Aber Ramdisks sind natürlich schon praktisch. Einen wirklichen Allzweckspeicher zu haben wäre schon, die Trennung auf Architekturebene sollte man aber schon aufrecht erhalten, am besten nicht nur durch eine Regelung der Zugriffe sondern auch weiterhin physisch indem man verschiedene Module für verschiedene Zwecke verwendet.
 
TrueAzrael schrieb:
Oder man geht tatsächlich in die Richtung mehr Speicher, wobei 20TB für einen Festspeicher jetzt nicht die Welt sind, aber scheinbar ja gerade für die Texturen von 10 Spielen reichen würde.
Denke mal ein paar Jahre weiter, um bei den Spielen zu bleiben, die sind derzeit zwischen 50-100gb groß. Natürlich sind z.B. Texturen komprimiert und Bibliotheken müssen in den Ram geladen werden. Wenn das Spiel jetzt ohne Kompression sagen wir 3-4 so groß ist sind wir bei 200-400gb aber du hast kaum noch Ladezeiten. nichts muss entpackt, vorgeladen oder vorgehalten werden, du hast nur noch die Berechnungsdauer des Prozessors^^.

Und statt wie heute 16Gb Ram und 1-2TB HDD hat man dann halt 10Tb im System, so unrealistisch ist das bei den Speicherwachstumsraten nicht.
Ergänzung ()

stalagg schrieb:
die Trennung auf Architekturebene sollte man aber schon aufrecht erhalten, am besten nicht nur durch eine Regelung der Zugriffe sondern auch weiterhin physisch indem man verschiedene Module für verschiedene Zwecke verwendet.
dann negierst du aber den potenziellen Vorteil wieder weil Daten geladen werden müssen. Um die Trennung und Schutz der Daten muss sich dann jemand anderes kümmern. Z.b. ein Speichercontroller, er könnte dann den Zugriff auf die Daten managen. Sprich ein Programm fordert arbeitsspeicherplatz an so kümmert sich der Controller um die Sperrung und Reservierung der Speicherbereiche sodass man eben nicht mal aus versehen den RAM löscht :D
 
Zuletzt bearbeitet:
rg88 schrieb:
und wer macht die Berechnung? Entpacken ist eine aufwändige Rechenoperation. Soll das die GPU noch nebenbei mitmachen?

Naja ist dann halt eine Frage was mehr sinn ergibt im jeweiligen System. Aktuell gibt es die Frage ja gar nicht.
Ähnlich dem genannten Beispiel bei ZFS. Ich kann mich noch erinnern als man komprimierten Daten auf einem Dateisystem eine klare Absage erteilte, weil die CPU eh schon genug zu tun hatte. Heutzutage hat die CPU entsprechend Leistung, dass es (lt. diverser Benchmarks) performanter ist die Daten komprimiert abzulegen und über die Lanes zu jagen.

rg88 schrieb:
Die nächste Quadratur des Kreises ;)

?
In der Regel gibt es verschieden komplexe Komprimierungsalgorithmen. Wenn ungepackte Daten zu viel Platz einnehmen, aber Daten die mit dem aktuellen Algorithmus gepackt sind mangels Rechenleistung nicht in "realtime" entpackt werden können, dann nehme man halt einen der weniger Leistung benötigt und dafür nicht so tolle packt. Und finde einen Mittelweg zwischen Rechenaufwand und Platzersparnis.

rg88 schrieb:
Gepackte Daten sind nutzlose Daten. Könnte man sie direkt ohne entpacken benutzen, müsste man sie ja im Grunde gar nicht packen, dann wär das ja das eigentliche Datenformat ;)

Damit meinte ich, dass die Daten im UltraRAM gepackt vorliegen und dann von der CPU/GPU in "realtime" entpackt werden. Bei ZFS z.B. funktioniert das, aber wie gesagt zwischen einem HDD/SSD-Raid und dessen Anbindung an die CPU und einem (Ultra)RAM-Baustein und dessen Anbindung and die CPU/GPU ist wohl ein himmelweiter Unterschied. Daher ja auch mein Hinweis das ich kein Experte bin, ich kann nicht abschätzen ob das realistisch möglich ist oder selbst mit dem simpelsten Algorithmus bereits zum scheitern verurteilt ist auf Grund der Zugriffszeiten und Geschwindigkeiten in dem Bereich.
 
  • Gefällt mir
Reaktionen: rg88
Zurück
Oben