Compressed RAM

[klumy]

Bei GRafikkarten gibt es ja mittlerweile die Option Texturen kompimiert im Arbeitsspeicher zu hinterlegen. Könnte man diese Option nicht allgemein für alle Sachen im Arbeitspeicher nutzen, so dass man mehr Objekte im Arbeitsspeicher nutzen kann.

[Mastermind]

Bei GRafikkarten gibt es ja mittlerweile die Option Texturen kompimiert im Arbeitsspeicher zu hinterlegen. Könnte man diese Option nicht allgemein für alle Sachen im Arbeitspeicher nutzen, so dass man mehr Objekte im Arbeitsspeicher nutzen kann.
;D
Das ist ziemlich unsinnig, weil im Arbeitsspeicher nicht nur Grafiken lagern, bei denen "Qualitätsverluste" erträglich sind. Würde es dir etwa nichts ausmachen, wenn in deinen frisch geschriebenen Office-Dokumenten plötzlich die ein oder anderen Buchstaben fehlen? :D
Es müsste also eine verlustfreie Kompression sein und das bringt einfach nicht viel. Der gesparte Platz wird durch die deutlich langsamere Bearbeitungszeit ins negative kompensiert.

[Gast]

könnte man machen, natürlich bräuchte man dann cpu-leistung um die daten on-the-fly für die bearbeitung zu (ent)packen.

das wäre ein relativ sinnloser tradeoff cpu-leistung für einen geringeren speicherverbrauch zu opfern.

zumal die daten zwingend verlustlos komprimiert werden müssen, und damit nicht vorhergesagt werden kann wie viel platz sie nun wirklich verbrauchen, was nochmals einige probleme mit sich bringt.

[aths]

Es gab immer wieder mal Versuche, wenigstens auf die Festplatte ausgelagerte Daten zu komprimieren. Das hat sich aber bis heute nicht durchgesetzt.

[BAGZZlash]

;D
Das ist ziemlich unsinnig, weil im Arbeitsspeicher nicht nur Grafiken lagern, bei denen "Qualitätsverluste" erträglich sind. Würde es dir etwa nichts ausmachen, wenn in deinen frisch geschriebenen Office-Dokumenten plötzlich die ein oder anderen Buchstaben fehlen? :D
Es müsste also eine verlustfreie Kompression sein und das bringt einfach nicht viel. Der gesparte Platz wird durch die deutlich langsamere Bearbeitungszeit ins negative kompensiert.

Datenkompression != Datenreduktion.

[Benedikt]

Sowas gabs mal von IBM (http://www.heise.de/newsticker/meldung/24772). Wurde aber eingestellt AFAIK.

[StefanV]

Tja, früher gabs auch mal 3DRAM -> RAM mit ROps.
EDRAM -> DRAM mit SRAM garniert, zuletzt gabs Versuche von VIA mit dem sog. VIrtual Channel RAM.
Es gab auch noch andere spezielle Grafikrams wie z.B. das dual Ported V-RAM oder W-RAM (WIndowed RAM, z.B. MGA 1x64W aka Millenium bzw 2).

Und noch ein paar andere Dinge wie z.B. MoSys Multibank DRAM und noch etwas, was ich gerad vergessen hab...

Leider hat sich ncihts davon wirklich durchgesetzt, auch nicht RLDRAM...

[Gast]

Payne das hat damit mal gar nichts zu tun...

[StefanV]

Doch, das da ein paar recht gute Ideen dabei waren, die sich aber nicht durchgesetzt haben, weils zu teuer/aufwändig sind oder aber mangelhafte Kompatiblität...

MBDRAM wurd z.B. nur beim Tseng ET6x00 eingesetzt, beim Nintendo N64 bin ich mir nicht sicher, ob da sowas drin ist...
WRAM war früher mal bei High End 3D Beschleunigern beliebt, bei MAtrox und Number 9, wurd von SGRAM verdrängt, gleiches beim VRAM...

Speicherkompression wirds nicht anders ergehen, Theoretisch ists ganz nett, praktisch aber recht aufwändig dazu stellt sich noch die Frage ob das ganze nicht ECC voraussetzt...
Zumal der Chipsatz das ganze allein machen muss...

[Xmas]

Generelle Speicherkompression ist ganz und gar nicht sinnvoll. Kompression ist entweder verlustbehaftet oder kann keine Reduktion der Daten garantieren, womit man dann mehr als den tatsächlich benötigten Speicherplatz reservieren müsste.

Wenn Daten im Speicher komprimiert gespeichert werden sollen, dann ist das Aufgabe der Anwendung. Denn die weiß am besten um welche Daten es sich handelt und wie darauf zugegriffen werden soll.

[anddill]

Es gab da mal ein Programm, hieß glaub ich Ramdoubler oder so ähnlich. Das hat angeblich den Ram in Echtzeit komprimiert. Wurde aber als Schwindel entlarvt.

[Gast]

Es gab da mal ein Programm, hieß glaub ich Ramdoubler oder so ähnlich. Das hat angeblich den Ram in Echtzeit komprimiert. Wurde aber als Schwindel entlarvt.

das kann ja am betriebssystem vorbei nicht funktionieren.

[Seraf]

MBDRAM wurd z.B. nur beim Tseng ET6x00 eingesetzt, beim Nintendo N64 bin ich mir nicht sicher, ob da sowas drin ist...


N64 hatte Rambus (RDRAM)
http://de.wikipedia.org/wiki/Nintendo_64

[KinGGoliAth]

naja. in anbetracht der tatsache, dass in halbwegs aktuellen rechnern 1gb drin ist und in den gamer pcs schon gerne mal 2gb oder noch mehr ist das imo unnötig, da "genug" platz zur verfügung steht und das im schlimmsten fall nur auf die cpu leistung schlägt.
bei quadcore wäre es evtl sinnvoll eine cpu mit dem komprimieren und dekomprimieren zu beschäftigen.
man hat ja genug cores. ;)
sonst eigentlich nicht.

und alte rechner, die nicht genug ram haben, haben dann auch eine entsprechend langsame cpu, die mit dieser aufgabe hoffnungslos überfordert wäre.

[Stone2001]

Generelle Speicherkompression ist ganz und gar nicht sinnvoll. Kompression ist entweder verlustbehaftet oder kann keine Reduktion der Daten garantieren, womit man dann mehr als den tatsächlich benötigten Speicherplatz reservieren müsste.

Wenn Daten im Speicher komprimiert gespeichert werden sollen, dann ist das Aufgabe der Anwendung. Denn die weiß am besten um welche Daten es sich handelt und wie darauf zugegriffen werden soll.
Speicherkompression ist bei modernen PC-Systemen nicht wirklich sinnvoll, anders sieht das bei eingebetteten Systemen aus. Dort macht zumindest die Kompression des Instruktionsspeicher durchaus Sinn, z.B. wenn die Kompressionseinheit weniger Strom verbraucht als (zusätzliche) Speicher.
Beliebte Kompressionsalgorithmen in diesem Bereich basieren auf dem Huffmancode, es gibt aber auch noch andere.

[Xmas]

Speicherkompression ist bei modernen PC-Systemen nicht wirklich sinnvoll, anders sieht das bei eingebetteten Systemen aus. Dort macht zumindest die Kompression des Instruktionsspeicher durchaus Sinn, z.B. wenn die Kompressionseinheit weniger Strom verbraucht als (zusätzliche) Speicher.
Beliebte Kompressionsalgorithmen in diesem Bereich basieren auf dem Huffmancode, es gibt aber auch noch andere.
Dort wird der Instruktionsstrom aber auch nur dekomprimiert, das komprimieren übernimmt der Compiler/Assembler. Was man in den Speicher schreibt, bleibt weiterhin genau so im Speicher vorhanden.

[BAGZZlash]

Leute, achtet auf die Begriffe. Datenkompression hat nix mit Datenreduktion zu tun. Klar, der durch die Daten belegte Speicherplatz soll durch Kompression reduziert werden, aber es werden keine Daten reduziert. Vgl. hierzu z.B. Audiocodecs: MP3 (verlustbehaftet durch Datenreduktion) vs. verlustfreie Codecs, die rein auf Datenkompression basieren.

Es gab da mal ein Programm, hieß glaub ich Ramdoubler oder so ähnlich. Das hat angeblich den Ram in Echtzeit komprimiert. Wurde aber als Schwindel entlarvt.

Ja, ich erinnere mich: Das war damals auch ein bißchen ein Experiment, wie viele darauf 'reinfallen und den Schmarrn glauben. Sogar große PC-Zeitschriften haben voller Euphorie vom neuen Heilsbringer berichtet... :rolleyes:

[Xmas]

Leute, achtet auf die Begriffe. Datenkompression hat nix mit Datenreduktion zu tun. Klar, der durch die Daten belegte Speicherplatz soll durch Kompression reduziert werden, aber es werden keine Daten reduziert. Vgl. hierzu z.B. Audiocodecs: MP3 (verlustbehaftet durch Datenreduktion) vs. verlustfreie Codecs, die rein auf Datenkompression basieren.
Warum die Wiederholung?

[BAGZZlash]

Warum die Wiederholung?

Weil Du den Fehler nach meiner ersten Ermahnung erneut gemacht hast... :eek: :wink:

[Xmas]

Weil Du den Fehler nach meiner ersten Ermahnung erneut gemacht hast... :eek: :wink:
Öhm, nein. Ich redete von "verlustbehafteter Kompression" was als Synonym für Datenreduktion durchaus gebräuchlich ist.

[BAGZZlash]

Öhm, nein. Du schriebst:

Kompression ist entweder verlustbehaftet[...]

Und Kompression ist niemals verlustbehaftet. Aber nun: EoD.

[Xmas]

Da es den Begriff "verlustbehaftete Kompression" gibt (das habe ich mir nicht ausgedacht ;)), gibt es auch "Kompression die verlustbehaftet ist", da dies lediglich eine grammatische Inversion ist.

[RavenTS]

Angesichts des weiterhin enorm schnell größer werdenden Hauptspeichers in PCs ist das wohl wirklich einfach unnötig. Effizienteste Programmierung würde da wohl mehr helfen, ist aber noch kostenintensiver als die langsamer wachsende CPU-Leistung für Kompression zu verwenden...