Sie haben den April-Scherz des diesjährigen LinuxUsers entdeckt. Eine "stromsparende Kompression", mit der man auch noch Speicherplatz einspart, ist nach wie vor ein Wunschtraum der Informatik.
Der von mir gewählte Ansatz erinnert ein wenig an das Programm Soft-RAM von Syncronys Softcorp, das 1995 für Furore sorgte -- zuerst, weil es alle nur denkbaren Preise für das beste Programm, Verkaufsschlager und Testsieger diverser Computer-Zeitschriften abräumte, bevor es von den Kollegen der c't-Redaktion als reines Placebo entlarvt wurde.
In der Praxis hängt es davon ab, aus welchen Gatter-Typen die einzelnen Speicherzellen aufgebaut sind, je nach dem, ob es sich um NAND oder NOR handelt, bedeutet eine hohe Spannung in der Speicherzelle eine logische Eins oder auch eine logische Null. Die Ursache für den Leckstrom ist jedoch im wesentlichen die Betriebsspannung der Transistoren, die unabhängig vom Ladezustand des Kondensators der jeweiligen Speicherzelle anliegt. Auch findet der RAM-Refresh unabhängig davon statt, ob in der Zelle eine Eins oder eine Null gespeichert ist.
Trotz allem wäre die im Artikel skizzierte Konvertierung des Speicherinhalts in möglichst viele Nullen tatsächlich umsetzbar. Allerdings kostet diese Konvertierung pro Byte zwei zusätzliche Bits, der Speicherverbrauch wächst daher um 25 Prozent -- Sie benötigen nach der Konvertierung 320 MByte RAM für den gleichen Inhalt, den Sie sonst in 256 MByte unterbekommen hätten. In der Tabelle ist dies nicht sofort zu erkennen, weil ich die beiden "Page-Flags" bewusst in eine eigene Spalte geschrieben habe, um Sie auf den Leim zu führen.
Die eigentliche Falle ist jedoch die anschließende Komprimierung des auf möglichst viele Nullen getrimmten Speicherinhalts. Das Ergebnis ist natürlich eine willkürliche Bytefolge, die keinerlei Optimierungen mehr enthält. Im Prinzip habe ich den Speicherinhalt erst um 25% vergrößert, um ihn dann wieder zu komprimieren. Letztlich kostet das ganze nur mehr Speicher und vor allem Rechenleistung.
Der Ansatz, durch Kompression der Speicherinhalte tatsächlich RAM zu sparen, ist indes nicht neu und auch keine Fiktion: Das im Artikel erwähnte CRAM-FS (Compressed ROM File System) gibt es tatsächlich. Es wird meist bei Mini-Distributionen und Rettungssystemen eingesetzt, die komplett ohne Festplattenzugriffe auskommen sollen. Der Kernel lädt zum Beispiel mit der Boot-Option "initrd=/boot/initrd.gz" das mit Gzip komprimierte Root-Dateisystem in den RAM, ohne es dabei auszupacken. Lediglich die akut benötigten Dateien werden im Hintergrund automatisch dekomprimiert. Somit ist ein CRAM-FS im Speicher tatsächlich kleiner, als es unkomprimiert wäre.
Der Nachteil des CRAM-FS ist jedoch, dass es lediglich lesenden Zugriff erlaubt -- die Dateien im CRAM-FS lassen sich nicht verändern. Das Collaborative File System benutzt dazu den Trick, eine Datei beim Ändern zunächst unkomprimiert im Speicher abzulegen und die Änderungen dort zu speichern. Im Nur-Lese-Teil des Collaborative FS bleibt die ursprüngliche Datei erhalten, es wird nur ein Verweis auf die unkomprimierte und veränderte Version im RAM angebracht.
Der Knackpunkt einer Speicherkompression in Realzeit ist nach wie vor die immense Rechenleistung, die dafür erforderlich wäre -- jede kleinste Veränderung bedeutet, dass der Speicherinhalt zunächst ausgepackt, verändert und erneut eingepackt werden muss. Die Alternative wäre, jede Datei einzeln zu komprimieren, mit dem Ergebnis, dass die Kompression insgesamt sehr schlecht und die Verwaltung noch aufwändiger würde.
Auch beim Problem des Leckstroms im Speicher habe ich übertrieben. Als Beispiel habe ich den sehr ungünstigen Fall eines SRAMs angeführt, der tatsächlich sechs Transistoren für jede Speicherzelle erfordert. Schnelle SRAMs werden jedoch nur sehr sparsam verwendet, etwa in Prozessor-Caches oder auf Grafikkarten. Der herkömmliche Arbeitsspeicher ist dynamischer RAM, kurz DRAM, der mit nur zwei Transistoren pro Speicherzelle auskommt. Noch dazu sind die Leckströme in der Realität um den Faktor fünf bis zehn kleiner als zwei Nano-Ampere pro Transistor, so dass die Leckstrom-Problematik derzeit nur auf den enorm dicht gepackten Prozessoren praxisrelevant ist. In naher Zukunft werden aber auch die Strukturen der Speicher-Chips weiter schrumpfen und die Leckströme zu einem ernsten Problem.
Auch bei der Bedeutung der Transistoren in TFT-Displays habe ich Sie an der Nase herumgeführt. Selbstverständlich leuchten die Transistoren nicht selbst, sondern sie steuern jeweils einen LCD-Punkt an. Für jedes Bildschirm-Pixel liegen drei LCD-Punkte direkt nebeneinander -- eins ist mit einer roten transparenten Folie, eins mit einer grünen und eins mit einer blauen hinterlegt.
Durch Ansteuerung des LCD-Punkts kann der Transistor einstellen, wie lichtdurchlässig der jeweilige Punkt (Sub-Pixel) wird -- von vollkommen transparent bis hin zu undurchsichtig. Das Licht stammt jedoch von den Leuchtstoffröhren am Rande des Displays, sind diese Leuchtstoffröhren abgeschaltet, ist das Display komplett dunkel. Dementsprechend gibt es auch kein KDE-Theme, das nur einen kleinen Bereich um den Maus-Pfeil anzeigt; diese Idee habe ich von einem KDE-Bildschirmschoner gestohlen.
Ich hoffe dass Ihnen der Aprilscherz gefallen hat und Sie auch nächstes Jahr wieder auf der Lauer liegen, wenn es wieder heißt: "April, April".
Ihr Mirko Dölle [mdoelle@linuxnewmedia.de]