Effiziente Kompressionsverfahren

[Dax]

Danke, ich sehs mir mal an :)

BtW: Ich habe den Huffman nicht implementiert, das war ein anderes fähiges angemeldetes Wesen ;)

read you,
Dax

[neogen]

Ich sehe grad, dass es um schnelle compression geht :) Also ich koennte hier noch

http://www.bitsum.com/jcalg1.htm

empfehlen, der macht sich gut und ist open source. und auch noch klein.

Folgendes wird erfuellt

• möglichst schnell - er ist schnell!
• hohe Abwärtskompatiblität (das Verfahren sollte auch noch unter einem 486-Prozessor, 16 MB RAM und Windows 95 laufen können) - weiss ich aber nicht genau, aber ist open source und in assembler
• möglichst geringer Ressourcenbedarf - das macht er!
• im Code möglichst kompakt - das ist er wirklich!

die kompressionsrate geht so, aber wenns schnell sein muss ist der hier gut :D

ich nutze den oefter fuer kleinere datenbanken und aehnliches, die in einen eigen format gespeichert werden.

cheers, neogen :)

PS: download http://www.bitsum.com/files/jcalg1_r534.zip

[Marphy]

Hallo zusammen!
Ich habe ein kleines Testprojekt zum Vergleichen der vielen vorgeschlagenen Kompressionsverfahren geschrieben (siehe Anhang).

Zwei Probleme:

• von alzirmar vorgeschlagenes, "sauschnelles" Verfahren funktioniert mit größeren Datenmengen nicht... Hab ich die Funktion falsch aufgerufen?
• JCALG1 (vorgeschlagen von neogen) läuft nur äußerst langsam.... Da ich Jordan Russells Interface-Unit aufgrund von der fehlenden OBJ-Datei nicht zum Laufen bringen konnte, habe ich diese einfach selbst geschrieben. Was hier schiefgelaufen ist, weiß ich jedoch nicht.

Hoffentlich wisst ihr weiter... :gruebel:

Gruß, Marco

[alzaimar]

Das von mir vorgeschlagene Verfahren funktioniert nur in Chunks à 32k (oder 64?). Schau einfach in den Code, dann siehst Du die Words. Wenn Du deine Daten so aufteilst, dann klappt das. Dann ist der Output eben immer ein Tupel (Länge, DATA) und nicht ein einziger Stream.

Übrigens ist es nicht 'fair' ein Kompressionsverfahren auf Zufallsdaten anzuwenden. Ein perfekter Zufallszahlengenerator zeichnet sich ja gerade dadurch aus, das er keine Redundanz erzeugt. Es wird sogar gemunkelt, das das Ergebnis einer Kompression (also der bytestrom) als sehr perfekter Randomgenerator taugt.

Viele Kompressionsverfahren, die in der freien Wildbahn recht schnell sind, beissen sich performancemässig an Zufallszahlen die Zähne aus. Nimm doch lieber Sourcecode oder irgendwelche EXE-files.

Ich habe dein testprogramm ein wenig modifiziert, damit 'mein' Kompressor auch zum Zug kommen kann und siehe da: Er versagt bei random-dateien und liegt ansonsten zwischen Huffman und zlib.

Ich habe einfach die EXE als Input genommen.

[Dust Signs]

@alzaimar: Könntest du uU eine EXE hochladen? Hab grade kein Delphi da und würde mir das gerne mal ansehen

Vielen Dank
Dust Signs

[Vjay]

Es wäre zuckersüß einen Beitrag einzugeben, nur um auf den Attachment hinzufügen-Button drücken zu dürfen?... seltsam

[alzaimar]

@Vjay: PrecTimer war im vorherigen Attachment drin und bei mir aus Gründen, die meinem Nick zu entnehmen sind, nicht. Unabhängig davon verstehe ich deine Zeilen nicht, aber der Sinn wird über die PNG klar.

@Dust Signs & Rest: Exe im Anhang

[Dust Signs]

Zitat:

Zitat von alzaimar

@Dust Signs & Rest: Exe im Anhang

Da fehlt eine DLL...

Dust Signs

[alzaimar]

Du wolltest nur die EXE, von DLL war keine Rede. Gibts nur gegen Aufpreis. Und überhaupt, sei nich so pingelig, is ja furchbar :mrgreen:

[Vjay]

Hab dann noch bzlib2 eingefügt.

Zitat:

davon verstehe ich deine Zeilen nicht

Diese Fehlermeldung kommt vom Board wenn du versuchst ein Attachment hochzuladen ohne vorher Text eingegeben zu haben.