Diskussion:Exomizer

Aus C64-Wiki
Zur Navigation springenZur Suche springen

Hallo!

ich sehe ein paar Verbesserungsmöglichkeiten wobei ich diese jetzt nicht direkt in den Artikel schreiben möchte, da dies vielleicht eher dem Autor unterbreitet werden sollte:

Verbesserungsmöglichkeiten[Quelltext bearbeiten]

Schnelleres Entpacken[Quelltext bearbeiten]

Wenn es nur auf die Anzahl der belegten Speicherblöcke ankommt, spielt es keine Rolle, ob ein Programm 16001 oder 16254 Bytes hat, es belegt beidesmal 64 Blöcke. Speicherbereiche, die nur um wenige Bits kürzer werden, könnte man durch unkomprimierte "literary" Bytes ersetzen. Da diese direkt Kopiert werden können und nicht aufwendig dekodiert werden müssen, verkürzt sich die Entpackzeit.

Variable Kodelängen[Quelltext bearbeiten]

Exomizer kodiert Referenzen auf Zeichenketten so, dass weite Referenzen längere Kodes erhalten als Nahe.

Ein unveröffentlicher Kompressor von Stefan Wolff (www.swolff.dk/cruncher/) arbeitet im Prinzip genau wie Exomizer, nur dass Speicherbereiche, die häufig referenziert werden, durch eine Art Speichersegmentierung mit weniger Bits kodiert werden können als Speicherbereiche mit wenig Referenzen. Eine Referenz auf ein Segment besteht aus x+y Bits: x ist konstant und wählt das Segment, während y den Offset innerhalb des Segments mit der Grösse 2^y bildet. Speichert man z.B. 2 Bits pro Segment, so sind Segmentgrössen von 2^n bis 2^(n+3) möglich - z.B. 16,32, 64 und 128 Bytes. Bei 256 Segmenten benötigt allein diese Tabelle 64 Bytes. Die Beispielprogramme sind im Vergleich zu Exomizer oft nur 40-100 Bytes kleiner. Dazu dauert das Entpacken ca 12% länger und benötigt relativ viel Speicher für die Tabellen.

Daher sein Entschluss, das Programm nicht zu veröffentlichen. 188.109.102.193 14:59, 24. Nov. 2012 (CET)


--- "...spielt es keine Rolle, ob ein Programm 16001 oder 16254 Bytes hat, es belegt beidesmal 64 Blöcke." Genau deshalb spielt es u.U. SEHR WOHL wohl eine Rolle, ob ein Programm X*254 Bytes Länge hat (2 Bytes verlinken auf nächsten Track/Sector), oder X*254+1 Byte. Ein einzelnes Byte kann also einen kompletten, neuen Block anknabbern und auf der Disk verschwenden! Somit hat der Cruncher von Stefan Wolff sehr wohl eine Bedeutung und hätte veröffentlicht werden sollen. Schade.

Schade finde ich, dass es zu Exomizer keinerlei Beschreibung über die Arbeitsweise gibt. Als Vorbild sehe ich da PuCrunch, wo immerhin viele Details zum Pack-Algorithmus beschrieben werden (wenn auch nicht gerade leicht verständlich). So ist der Exomizer eine Blackbox nach dem Motto "Friß oder stirb!". Schade.