DataLight - Per Software aufgemotzt

Da soll es doch noch Leute geben, die einen Schuhkarton zu Hause stehen haben. Nein, keinen aus Pappe, sondern einen aus Metall mit der Aufschrift „SH204“. Es handelt sich also um eine der Festplatten aus der Anfangszeit des ST. Mit einer Kapazität von sage und schreibe 20 MByte war dieses Teil vor einigen Jahren noch hochmodern.

Nun, die Zeiten haben sich geändert. Daß es immer noch ST-Anwender gibt, die mit dieser Platte arbeiten, spricht vielleicht ausnahmsweise einmal für ein gewisses Maß an Qualität, über die ja bei manchen Atari-Produkten gestritten wird. Heutzutage ist jedoch nicht mehr nur Qualität, sondern, zumindest was Datenträger betrifft, auch Quantität gefragt. Festplatten mit weniger als 50 MByte Kapazität sind für Atari-Computer höchstens noch gebraucht erhältlich. Für Platten jenseits der 50 MByte-Grenze bezahlt man heutzutage weniger, als ursprünglich die SH204 gekostet hat. Läßt sich festhalten, daß nicht nur die Computer, sondern auch Massenspeicher einen merklichen Preisverfall mitgemacht haben.

Alte Besen kehren gut...

... besonders dann, wenn man sich so das Geld für einen neuen sparen kann. Im Klartext: Wer eine Festplatte in erster Linie für die Speicherung größerer Datenmengen nutzt und nicht so sehr auf eine hohe Geschwindigkeit bei der Datenübertragung angewiesen ist, dürfte auch mit einer Platte älteren Datums leben können, vorausgesetzt sie hat eine ausreichende Kapazität. Der Kauf einer neuen Festplatte reißt schließlich trotz gesunkener Preise ein Loch in den Geldbeutel, was je nach Finanzlage nicht unbedingt in Frage kommt. So können also scheinbar unvereinbare Wünsche aufeinandertreffen. Einerseits gibt es den Bedarf nach größerer Speicherkapazität, andererseits kommt eine neue Platte nicht in Betracht. Eine Lösung wäre es, könnte man auf der gleichen Festplatte deutlich mehr Daten unterbringen. Leider läßt sich die Kapazität einer Fest- oder Wechselplatte aber nicht durch einen Software-Trick erhöhen, oder etwa doch?

Kompression statt Depression

In der Tat läßt sich diese Frage bejahen, wenn auch mit Einschränkungen. Das Zauberwort heißt hier Datenkompression. Vielleicht sind Sie ja schon auf eines der zahlreichen Programme gestoßen, die diese Möglichkeit bieten. Schließlich gibt es auf diesem Sektor reichlich Software. Es sollen hier lediglich altbekannte Programme wie ARC, LHARC und ZOO erwähnt werden. Dabei handelt es sich um Software, mit deren Hilfe mehrere Dateien komprimiert in einer einzigen Archivdatei zusammengefaßt werden können.

Bild 1: Der Aufbau eines Binärbaums

Wie stark Daten mit solchen Archivierungsprogrammen gepackt werden können, hängt eng mit dem vorliegenden Datenformat zusammen. Besonders groß kann die Platzersparnis bei Texten oder Bilddateien ausfallen. Hier tauchen besonders häufig wiederkehrende Muster oder gar gleiche Zeichen in Folge auf, und diese lassen sich relativ leicht in eine komprimierte Form bringen. Programmdateien dagegen sind typische Problemfälle bei der Datenkomprimierung, da sich wiederholende Muster hier eher eine Ausnahme darstellen.

An dieser Stelle sollte ich vielleicht einige Worte darüber verlieren, wie eine Komprimierung von Daten überhaupt vonstatten gehen kann.

Grundlagen

Werfen wir doch einmal einen Blick auf eine reine Textdatei. Eine sehr einfache Art der Komprimierung wäre es, für jedes Zeichen, also Buchstaben oder Ziffern, nicht die üblichen 8 Bits, sondern einen Code mit nur 7 Bits zu verwenden. Da alle Buchstaben des deutschen Alphabets inklusive Umlauten und Ziffern nicht mehr als 128 Zeichen ausmachen, ein achtes Bit in diesem Fall also nicht benötigt wird, ließe sich ein Text ohne besonderen Aufwand um bis zu 12.5% komprimieren. Es würde genügen, lediglich das achte Bit jedes Zeichens zu entfernen und stattdessen ein Bit eines anderen Zeichens an diese Stelle zu setzen.

Ein Ansatz, der einen großen Schritt weiterführt, berücksichtigt für die Komprimierung die Häufigkeit, mit der einzelne Zeichen auftauchen. Schaut man sich einen deutschsprachigen Text an, stellt man fest, daß bestimmte Buchstaben (besonders Vokale) häufig, andere eher selten auftreten. Dieser Umstand bildet die Basisidee für einen Codierungs-Algorithmus, der von David Huffman stammt. Im Rahmen der Huffman-Komprimierung wird den einzelnen Zeichen einer Datei keine feste Zahl an Bits zugewiesen, sondern es wird mit variablen Längen gearbeitet. Ein Zeichen, das häufig vorkommt, wird beispielsweise in 4 Bits codiert, andere Zeichen können durchaus mehr als 8 Bits benötigen. Entscheidend für die Effizienz der Komprimierung ist. daß die häufigsten Zeichen mit möglichst wenigen Bits dargestellt werden. Bei der Umsetzung von Bytes in Bit-Folgen müssen Doppeldeutigkeiten natürlich vermieden werden. Sind beispielsweise fünf Zeichen a bis a5 zu codieren, wäre folgende Zuordnung nicht zulässig:

a1 01 
a2 10 
a3 11 
a4 001 
a5 010

Die für a5 gewählte Bit-Folge beginnt mit der gleichen Sequenz, die auch für a1 verwendet wurde, was bei der Decodierung zu einem Fehler führen würde. Bei der Umsetzung der 256 möglichen Bit-Kombinationen. die durch ein Byte repräsentiert werden, müssen die gewählten Sequenzen so beschaffen sein, daß man eine eindeutige Zuordnung erhält.

Binärbäume

Das Aufstellen einer für die Huffman-Komprimierung geeigneten Zuordnung zwischen Bytes und Bit-Sequenzen scheint auf den ersten Blick nicht so einfach zu sein. Wie gelangt man möglichst einfach an eine Tabelle, die die Regeln für die Komprimierung der einzelnen Zeichen enthält?

Sehr anschaulich läßt sich dieses Problem mit Hilfe eines Binärbaumes lösen. Solche Bäume unterscheiden sich von den aus der Natur bekannten durch eine etwas ungewöhnliche Struktur: Die Blätter eines Binärbaums wachsen nämlich nach unten (Bild 1). Um anhand eines Binärbaums für ein bestimmtes Zeichen dessen Codierung zu erfahren, verfolgt man einen solchen Baum einfach von oben nach unten und reiht die den Verzweigungen zugeordneten Werte (0 oder 1) aneinander.

Im Rahmen einer Komprimierung nach Huffman dreht sich also alles darum, den für die Codierung benötigen Binärbaum zu erhalten. Dazu existiert ein mehrstufiges Schema, das sich recht leicht in ein Programm umsetzen läßt:

Zunächst einmal werden die Bytes der zu komprimierenden Datei gemäß abnehmender Häufigkeit geordnet. Man erhält eine Liste, in der im folgenden stets nur die letzten beiden Elemente betrachtet werden. Diese werden zu einem Knoten mit zwei Blättern zusammengefaßt und neu in die Häufigkeitsliste eingeordnet. Die Position des Knotens ergibt sich dabei aus der Summe der Häufigkeiten der beiden Blätter. Dieses Verfahren wird so lange angewendet. bis nur noch ein Eintrag in der Liste übrigbleibt. Bei diesem handelt es sich um das am häufigsten auftretende Element, das ganz oben im Binärbaum angesiedelt wird.

Die Bilder 2 und 3 veranschaulichen diese Vorgehens weise anhand eines Binärbaums, der für sieben Elemente angelegt wird [1]. Die Häufigkeiten der Teilelemente sind jeweils angegeben. Aus dem so erzeugten Baum läßt sich für jedes Zeichen leicht ablesen, wie die Codierung zu erfolgen hat. Es ergibt sich folgende Verschlüsselung:

a1 10 
a2 000 
a3 001 
a4 010 
a5 110 
a6 111 
a7 0110 
a8 0111

Wie man sieht, benötigen die häufig auftretenden Zeichen weniger Bits als die selteneren. Genau dies wird durch den Huffman-Algorithmus gewährleistet.

Um eine optimale Komprimierung zu gewährleisten, sollte für jede Datei eine individuelle Baumstruktur ermittelt werden. Sofern man ausschließlich an der Komprimierung von Textdateien interessiert ist, kann man darauf verzichten, für jede Datei einen neuen Binärbaum zu berechnen. Da die Häufigkeiten einzelner Buchstaben der deutschen Sprache nachgeschlagen werden können, kann mit einer festen Liste gearbeitet werden. In diesem Fall erübrigt es sich, der komprimierten Datei die Struktur des Binärbaums mitzugeben, da der Dekomprimierer von einem feststehenden Aufbau ausgehen kann.

Eine andere Basis für die Komprimierung von Daten stellt das von Lempel, Ziv und Welch entwickelte LZW-Verfahren dar, auf das ich hier nur kurz eingehen möchte. Man kann davon ausgehen, daß sich innerhalb einer Datei gewisse Byte-Folgen wiederholen. Werden solche Mustercodiert. indem man vermerkt, wo dieses zum ersten Mal auftaucht und wie lang es ist, ergibt sich eine sehr wirkungsvolle Komprimierung. Im Falle einer Textdatei lassen sich so ganze Wörter oder gar Satzteile je nach Realisierung des LZW-Algorithmus in zwei Bytes unterbringen.

Bild 2: Von der Häufigkeit zum Binärbaum

Neue Wege der Komprimierung

Nun aber wieder zurück zur Praxis. Eine Komprimierung, wie sie von Archivierungsprogrammen durchgeführt wird, ist nicht unbedingt das Gelbe vom Ei. Gut geeignet sind solche Programme lediglich dann, wenn man große Datenmengen nicht ständig parat haben muß und deshalb platzsparend unterbringen will. Für Daten, auf die man ständig zugreift, bringt eine Archivierung zwar eine Ersparnis an Speicherplatz, es ist jedoch wenig praktikabel, Dateien vor jeder Benutzung zunächst auszupacken und anschließend wieder im Archiv verschwinden zu lassen. Man stelle sich das einmal vor: Zunächst wird die Textverarbeitung entpackt, anschließend der zu bearbeitende Text. Nachdem dieser durch die Mangel gedreht wurde, geht es daran, die Textdatei erneut zu archivieren und so Platz für andere Anwendungen zu schaffen.

Das hört sich nicht nur umständlich an, sondern ist es auch. Da wäre es doch nicht schlecht, wenn sich die Textverarbeitung nach dem Programmstart gleich selber entpacken würde. Und noch toller wäre es, wenn das Textprogramm einen komprimierten Text während des Ladens automatisch entpacken würde, ohne daß man sich hierum kümmern müßte. Klar, daß der Text beim Speichern auch wieder automatisch komprimiert werden soll, denn man will es ja so einfach wie möglich haben. Auf den Punkt gebracht: Es müßte möglich sein, die Datenkomprimierung und auch die Dekomprimierung unauffällig im Hintergrund ablaufen zu lassen.

Bild 3: Binärbaum in Vollendung

Keine Kalorien bitte

Ein Programm für den Atari, das diese Aufgabe bewerkstelligt, ist DataLight, wobei der Name für dieses Produkt sicherlich nicht purer Zufall ist. DataLight be steht eigentlich aus zwei Bestandteilen. Da findet sich zum einen der Treiber, der dafür sorgt, daß Daten auf bestimmten Partitionen je nach Bedarf ent- oder gepackt werden. Ferner gibt es ein Installationsprogramm, mit dem man einzelne Partitionen für die Komprimierung vorbereiten und nachkomprimieren kann.

Bevor DataLight seinen Dienst verrichten kann, müssen die zur Komprimierung anstehenden Disketten oder Festplatten-Partitionen zunächst in ein spezielles Format überführt werden. Dabei werden dummerweise alle bisherigen Daten auf diesen Partitionen gelöscht. In der Regel dürfte also erst einmal ein Backup fällig sein, denn die Daten sollen zu einem späteren Zeitpunkt ja wieder zurückgeschrieben werden. Befinden sich auf einer zu komprimierenden Partition also größere Datenmengen, kommt man um zeitraubende Transaktionen nicht herum, bevor die eigentliche Komprimierung stattfinden kann. (Soll ein komprimiertes Medium irgendwann einmal dekomprimiert werden, geht auch dies nur unter Datenverlust.)

Ist die Initialisierung beendet, präsentiert sich die ausgewählte Partition auf den ersten Blick völlig normal mit einem leeren Directory. Daß sich etwas geändert hat, stellt man erst dann fest, wenn Daten auf diesem Laufwerk untergebracht werden. Ganz so schnell wie auf nicht komprimierten Partitionen läuft dieser Vorgang nämlich nicht mehr ab. Bei jedem Zugriff erhält nun der DataLight-Treiber die Kontrolle und komprimiert oder dekomprimiert die Daten, je nach Bedarf. Andere Programme bemerken von diesen Vorgängen nichts, lediglich dem Benutzer fällt auf, daß die Platte irgendwie behäbiger zu arbeiten scheint.

Zwei Verfahren zur Auswahl

DataLight stellt dem Benutzer zwei Methoden zur Datenkomprimierung bereit. Dabei handelt es sich um die bereits angesprochenen Huffman- bzw. LZW-Algorithmen. Eine weitere Variante mit der Bezeichnung LHW soll in zukünftigen Versionen von DataLight implementiert werden. Werden mehrere Partitionen komprimiert, kann für jede Partition ein anderes Pack verfahren ausgewählt werden.

Eine echte Komprimierung während des Schreibens von Daten stellt bei DataLight eigentlich nur der Huffman-Algorithmus dar, der eine Komprimierung um bis zu 40% erlauben soll. Beim LZW-Verfahren werden die Daten dagegen nicht on-line komprimiert, sondern zunächst ungepackt auf das Medium geschrieben. Dies führt zu einer höheren Geschwindigkeit bei Schreiboperationen, bringt aber den Nachteil mit sich, daß LZW-komprimierte Partitionen in einem getrennten Arbeitsgang nach bearbeitet werden müssen, um auf den angegebenen Komprimierungsgrad von bis zu 60% zu kommen. Der Anwender entscheidet also selber, ob er an einer normalen Online-Komprimierung interessiert ist, oder zugunsten höherer Geschwindigkeit das LZW-Verfahren mit nachträglicher Komprimierung wählt.

Bild 4 & Bild 5: Komprimierung erwünscht?
  unkomprimiert Huffman LZW
  Lesen Schreiben Lesen Schreiben Lesen Schreiben
FUJITSU 5 / 11 28 / 126 11 / 35
SQ555 16 / 28 37 / 172 18 / 160

Tabelle 1: Der TT-Test (alle Werte in Sekunden).

  unkomprimiert Huffman LZW
  Lesen Schreiben Lesen Schreiben Lesen Schreiben
SQ555 6 / 6 65 / 72 16 / 8

Tabelle 2: Der ST-Test (alle Werte in Sekunden).

Geschwindigkeit ist keine Hexerei

Was den Zeitbedarf für das Laden und Speichern bei installiertem DataLight betrifft, so hängt dieser bei komprimierten Partitionen neben dem verwendeten Pack-Algorithmus von weiteren Faktoren ab. Zum einen ist es natürlich von Bedeutung, mit welchem Computer man arbeitet. Schließlich hängt die Zeit, die für die von DataLight vorgenommenen Operationen benötigt wird, von der jeweiligen Rechenleistung ab. Wer also einen schnellen Rechner mit langsamer Festplatte besitzt, kann bei Verwendung von DataLight unter Umständen mit einer leichten Beschleunigung beim Laden großer Dateien rechnen. Dadurch, daß die benötigten Daten komprimiert vorliegen, halten sich die Festplattenzugriffe in Grenzen, und die Zeit, die für das Entpacken benötigt wird, ist für die Gesamtgeschwindigkeit ausschlaggebend. Umgekehrt sieht es natürlich bei schnellen Platten und langsamen Rechnern aus. Hier kann die Zeit, die für das Dekomprimieren der Daten benötigt wird, durchaus spürbar werden. (Um Zeitverluste durch langsame Peripheriegeräte auszugleichen, ist DataLight übrigens mit konfigurierbaren Caches ausgestattet.)

Alles in allem darf man davon ausgehen, daß Besitzer eines Atari TT mit der standardmäßig ausgelieferten, relativ langsamen Festplatte ST157N in Verbindung mit DataLight kaum einen Zeitverlust beim Laden von Programmen spüren werden. Anders sollte es dagegen bei einem Atari ST aussehen, wenn an diesem eine schnelle Festplatte mit Cache betrieben wird.

Einfluß der Rechnerausstattung

In der Praxis konnte diese Einschätzung im großen und ganzen bestätigt werden. Um näher zu beleuchten, wie sich DataLight mit unterschiedlichen Gerätekombinationen verhält, wurde das Programm sowohl auf einem normal getakteten Atari ST als auch einem TT getestet. Der ST war mit einer Wechselplatte SQ555 ausgestattet, am TT wurden zusätzliche Tests mit einer schnellen SCSI-Festplatte FUJITSU M2624S durchgeführt. (Meßwerte von RATEHD für beide Platten am TT: SQ555: 500 KByte/s, FUJITSU: 1700 KByte/s.)

DataLight mußte sich zunächst an umfangreichen Kopieroperationen beweisen. Auf dem TT wurde mit Hilfe des KOBOLD-Dateikopierers eine komplette Festplatten-Partition mit ca. 6 MByte an Daten eingelesen und anschließend auf leere, umkomprimierte Partitionen geschrieben. Nun wurden die gleichen Daten auf den vom DataLight-Treiber verwalteten komprimierten Partitionen untergebracht. Abschließend wurden die komprimierten Daten wieder mittels KOBOLD in den Hauptspeicher transferiert. Das Ergebnis präsentiert sich in Tabelle 1, wobei die Zahlen selbstverständlich als Zeitangaben in Sekunden zu verstehen sind.

Beim ST wurden aufgrund mangelnden Hauptspeichers lediglich 2 MByte an Ordnern und Dateien hin- und hergeschoben. Das Resultat kann man in Tabelle 2 finden.

Der DataLight-Treiber befand sich bei der Arbeit am TT im ST-RAM, da er im TT-RAM nicht lauffähig ist. Gerade bei einem solch rechenintensiven Programm wäre die Unterstützung des TT-RAMs natürlich sinnvoll. Die Zeiten für das LZW-Verfahren beziehen sich jeweils auf die bereits nachkomprimierte Partition. Man erkennt den deutlichen Zeitvorteil, den die Verwendung das LZW-Algorithmus’ mit sich bringt. Für das Komprimieren der 6-MByte-Partition im LZW-gepackten Format benötigte der TT allerdings 14, der ST sogar 43 Minuten.

Ungewöhnlich lange benötigte das LZW-Verfahren auf dem TT für das Schreiben von Daten auf die Wechselplatte am ACSI-Bus. Die Ursache hierfür konnte nicht geklärt werden.

Auf den zweiten Blick

Die gemessenen Zeiten zeigen sehr gut, daß der Zeitverlust durch den Einsatz von DataLight umso geringer wird, je langsamer die verwendete Festplatte und je schneller der Rechner ist. Bei der Bewertung der gemessenen Zeiten, die zum Teil im Minutenbereich liegen, muß man im Hinterkopf behalten, daß sich diese Angaben auf eine ungewöhnlich große Datenmenge beziehen. Häufig beschränkt sich die Arbeit am Rechner auf das Starten von Programmen und das Lesen und Schreiben von Dateien durchschnittlicher Größe. Hier fällt es nur wenig ins Gewicht, ob für das Laden einer Datei eine Sekunde mehr oder weniger benötigt wird. 28 Sekunden stellen verglichen mit 5 Sekunden für das Laden von Daten sicherlich schon fast eine Ewigkeit dar. 3 Sekunden statt einer halben Sekunde mögen da schon erträglicher erscheinen, auch wenn in beiden Fällen der Faktor 6 zugrunde liegt. Was eine Bewertung dieser Zeiten betrifft, soll das Urteil dem Anwender überlassen bleiben.

Hinters Licht geführt

Nun ist es ja nicht so, daß sich Festplattenzugriffe lediglich auf das Laden und Speichern von Dateien sowie das Starten von Programmen beschränken. So manipulieren insbesondere Datenbanken keine kompletten Dateien an einem Stück, sondern bearbeiten lediglich einzelne Datensätze, die sich innerhalb einer großen Datei befinden. über relative Zugriffe. Ebenfalls kritisch für eine On-Line-Komprimierung sind Disk-Monitore, mit denen auf niedriger Ebene Veränderungen am Inhalt einzelner Sektoren vorgenommen werden können.

Trotz intensiver Bemühungen war es nicht möglich. DataLight durch ungewöhnliche Zugriffsversuche aus dem Tritt zu bringen und hierdurch einen Datenverlust hervorzurufen. Auch die Anwendung eines Festplatten-Optimizers auf komprimierte Partitionen ist möglich, wenn auch deutlich langsamer als bei unkomprimierten Laufwerken. Selbst Manipulationen per Disk-Monitor ließen sich durchführen. ohne daß man die Anwesenheit des DataLight-Treibers bemerkt hätte.

Apropos Treiber: Die einzige Möglichkeit, ein korrektes Arbeiten von DataLight zu unterbinden, dürfte darin bestehen, nach DataLight einen Festplattentreiber zu starten. In diesem Fall werden nämlich die DataLight-Routinen zwangsweise deaktiviert. Anstatt eines Directories zeigt der Desktop für komprimierte Partitionen nun lediglich Dateien an. die allesamt den gleichen Namen tragen, ohne daß es möglich wäre, schreibend auf diese Daten zuzugreifen. Hierbei handelt es sich um eine Art Sicherheitsmechanismus. DataLight ist also gegen solche Eventualitäten abgesichert.

Die Anwendung entscheidet

Der Punkt ist erreicht, zu einer Gesamtbewertung von DataLight zu schreiten. Die im DataLight-Handbuch geweckte Hoffnung, Zeitgewinne beim Laden von Daten verbuchen zu können, erfüllte sich im Rahmen dieses Tests nicht. Mit Verzögerungen beim Bearbeiten von komprimierten Daten muß man also leben. Ob man DataLight als Anwender vorteilhaft einsetzen kann, hängt in erster Linie von der jeweiligen Gerätekonfiguration sowie vom subjektiven Geschwindigkeitsempfinden ab. Für schnelle Festplatten hoher Kapazität empfiehlt sich DataLight kaum, da die Komprimierungs-Algorithmen auf kleine Partitionen abgestimmt sind. Das Programm ist in erster Linie für denjenigen interessant, dem es weniger auf die Geschwindigkeit beim Datentransfer als vielmehr auf die Speicherkapazität seiner Platte oder Diskette ankommt. Hier hat man für 99 DM die Gelegenheit, seine Medien kräftig aufzublasen.

Neue Version

Kurz nach Redaktionsschluß erreichte uns noch ein Anruf aus dem Hause LogiLex, daß zur CeBIT, also bereits, wenn Sie diese Zeilen lesen, eine neue, deutlich schnellere Version von DataLight vorgestellt wird. Leider konnten wir diese Version bei diesem Testbericht nicht mehr berücksichtigen.

Literatur:

[1] Frank Streichen, „Informationsverschwendung - Nein danke", c't 1987

Bezugsadresse:

LogiLex - Gerhard Oppenhorst Eifelstraße 32 W-5300 Bonn 1


Uwe Seimet
Aus: ST-Computer 04 / 1992, Seite 156

Links

Copyright-Bestimmungen: siehe Über diese Seite