XZ - das Kompressionswunderwerkzeug

[DeletedUserReAsG]

Ja, hab’s gerade ausprobiert → funktioniert, wie’s soll

Edit, noch etwas on-topic: hat pixz nennenswerte Vorteile gegenüber der xz-eigenen Multithreadoption?

Code: Alles auswählen

  -T, --threads=ZAHL    Erzeuge höchstens ZAHL viele Threads; die Grund-
                        einstellung ist 1. Wenn der Wert 0 angegeben wird, dann
                        werden so viele Threads erzeugt, wie es Prozessorkerne
                        gibt

[heisenberg]

pixz bringt bei hoher kompression gar nix. Beim Messen von der Stufen -3,-6 und -9 gibt es nur bei den ersten beiden die Multi-CPU-Power. Bei -9 ist der Zeitverbrauch wie bei Single-Thread-xz.

Code: Alles auswählen

Testname      Testfile Dur.(Sec) CPU-Time Used RAM ComprSize    Compr. Ratio
============================================================================
pixz -9 16x   img_jpg    35.09    35.01   678248   50567988         88.07 %
pixz -3 16x   img_jpg     5.56    34.85   325925   55426356         96.54 %
pixz -1 16x   img_jpg     3.89    39.85   205131   55504028         96.67 %

Die xz-mutlithreaded-Option habe ich bisher noch gar nicht bemerkt. Nehme ich auch nochmal mit dazu. Mittlerweile dauert das aber ganz schön lange, da pro Test 20 Runden durchgeführt werden um halbwegs sauber gemittelte Testergebnisse zu bekommen.

In der Manpage steht auch dieses hier:

Multithreaded compression and decompression are not implemented yet, so this option has no effect for now.

[wanne]

pixz bringt bei hoher kompression gar nix.

Das ist so nicht richtig. -1 bis -9 vergrößert vor allem das Dictionary. (-1 bs -3 spielen noch am Match finder rum um etwas schneller zu sein) -9 hat eines von 64MiB. Bei einer Dateigröße von 48MiB sind da schonal 15MiB aus Prinzip ungenutzt. Für Dateien <32MiB sind -8 und mit -9 identisch in der Kompression. Ein Dictionary, das größer als die Datei ist, ist sinnlos. Eines das nur minimal kleiner als die Datei ist, ist fast sinnlos.

Paralellisiert wird indem die Datei in Chunks eingeteilt wird. Chunks die gleichzeitig komprimiert werdend können nicht gegeneinander komprimiert werden. Wenn du von deinem 64MiB Dictionary profitieren willst, sollte also mindestens die ersten 64MiB am Stück lassen und in einen Chunk packen. Bei 48MiB Dateigröße bist du dann singlethreated.
Damit vernünftig Parallelisiert werden kann solltest du mindestens die ~10-fache DictSize pro Thread haben. Eher etwas mehr.

Wenn du größere Kompression nur auf kosten der CPU und nicht auf kosten des Speichers (der nunmal durch die Dateigröße begrenzt ist) haben willst kannst du den "mode" umstellen (-e) oder "nice" hochsetzen. Ähnlich verghällt sich die mit "depth". Da gute werte zu ermitteln ist allerdings schwer.
Zuletzt sollte noch angemerkt sein, dass die Parallelisierung sinlos ist ohne genügend RAM. DictSize*Threads*10 ist sinnvoll. dh. für -9 und 4 Threads mindestens 2,5GiB
Das gleiche gilt für die Ursprungsdatei. Um vernünftig testen zu können sollte deutlich größer als 2,5GiB sein.

Für kleinere Dateien lohnen sich höhere Kompressionsstufen/Multithreading nicht.

Ansonsten: jpeg hat schon ein verlustfreies Kompressionsverfahren am Ende. Das ist zwar nur eine Entropiekodierung aber dadurch ein recht störrisches Objekt. Gerade bzip2 das am ende ebenfalls eine Entropiekodierung hat dürfte da unfair benachteiligt sein, wenn man vergleicht.

[DeletedUserReAsG]

heisenberg, pixz war bei dir das, was den kaputten Tarball angemeckert hat. Offensichtlich versucht’s, die Inhalte des Archivs gleichmäßig auf die Threads zu verteilen, wozu es das natürlich erstmal einlesen muss und bei kaputter Datei einen Fehler wirft. In dem Kontext ist’s okay – man kann die „tar-Erkennung“ auch unterbinden.

Ich wollte gerade mal pixz und xz mit ähnlichen Parametern (-9) auf ein getartes ~/.thunderbird (~280MB, bunte Mischung aus mehr oder weniger gut komprimierbaren Daten – überwiegend aber wohl gut, das Ergebnis ist nur noch rund ein Drittel so groß) loslassen, leider braucht’s mehr RAM, als ich auf diesem Kistchen zur Verfügung habe → es swappt, als Messung ist’s unbrauchbar, allerdings ist bis dahin der angezeigte Durchsatz mit -T 2 ~60% höher, als mit -T 1 an der gleichen Stelle, Letzteres ist aber aufgrund des geringeren Speicherverbrauchs (und daher ohne zu swappen) unterm Strich 30% schneller. Ein 100MB-Stück der obengenannten Datei wird bei mir jedoch immer mit einem Thread abgearbeitet, egal, was ich mitgebe. pixz bringt’s System bei dem 280MB-Tarball wieder zum Swappen (zeigt aber im Gegensatz zu xz den momentanen Durchsatz nicht an), beim 100MB-File (mit -t explizit nicht als Tarball behandelt, da sonst die erwähnte Fehlermeldung kommen würde) sind Zeit und Kompressionsrate vergleichbar mit xz bei einem Thread, es wurde überwiegend auch nur ein Kern genutzt.

Um vernünftig testen zu können sollte deutlich größer als 2,5GiB sein.

Kommt drauf an, was man testen will – wenn man üblicherweise auf älterer Hardware Backups von einzelnen Verzeichnissen zusammenpackt (wo ~/.thunderbird auf ’nem Desktopsystem ja ein typischer Kandidat wäre), bringt’s einem nicht viel, wenn man weiß, dass pixz bei ’nem aus 2 1.25GiB-Textfiles bestehenden 2.5GiB-Tarball und ausreichend RAM schneller wäre. Wenn’s um ’nen rein technischen, also in der Praxis irrelevanten, Vergleich gehen sollte, sollte man hingegen schon zusehen, dass die Ausgangsbedingungen möglichst optimal sind, da stimme ich zu – wenn ich allerdings einen Packer für eine konkrete praktische Anwendung suche, etwa für ein Backup auf einer gegebenen Maschine, würde ich die Kandidaten konkret mit diesem Backup auf dieser Maschine testen.

[wanne]

OK, ich muss mich wohl nochmal verbessern: Für kleine Dateien ist -9 einfach nicht sinnvoll. Das wird in der man-Page ausdrücklich erwähnt. Selbstverständlich ist das Ergebnis aussagekräftig für diese Datei. Wenn aber schon in der man-page steht, dass die Parameter für die Datei unsinnig sind, sollte man sich nicht wundern, wenn das nicht so genial ist, was da raus kommt. (Und eben nicht auf andere Dateien schließen.)
Die höheren Kompressionsstufen sind bei xz definitiv mit Vorsicht zu genießen und sollten eben nur da eingesetzt werden wo sie sinnvoll sind. (Wenn man viel RAM Zeit und große Dateien hat.)

Bisschen wie volle Plastikflaschen an die Schleifmaschine halten. Man wird feststellen, dass sie sogar schneller kaputt gehen, als Glasflaschen. Das Ergebnis ist richtig. Und wenn das dein Threat model ist, definitiv der richtige Test. Der Test ist aber auch sinnloß weil man das ohne weiteres auch ohne Experiment vorhersagen kann. Die schlussfolgern dass Plastikflaschen schneller kaputt gehen als Glasflaschen ist dagegen vollständig falsch.

Ansonsten komprimiert die multithreadded Variante etwas schlechter als xz. Ich würde mir bei wenig RAM und 280MB massiv überlegen, ob man nicht besser -8 und xz nutzt. Dürfte vermutlich ähnliche Ergebnisse in der Größe haben aber dafür schneller laufen.

[DeletedUserReAsG]

Der Test ist aber auch sinnloß weil man das ohne weiteres auch ohne Experiment vorhersagen kann.

Ach wanne, du weißt doch, dass ich ’n doofer Noob bin, und sowas nicht vorhersagen kann. Wenn ich also Packer vergleiche, komprimiere ich damit jeweils die gleiche Ausgangsdatei (mit Daten, die ich auch im Normalfall komprimieren würde) mit höchstmöglichem Kompressionslevel und schau’, wer‘s wie schnell bei wieviel RAM-Verbrauch wie klein macht. Der Gewinner ist fortan mein Favorit und gut. Leute, die detaillierter wissen, wie‘s funktioniert, mögen das nicht nötig haben, die sagen „sieht man doch, dass pixz schlechter komprimiert“. Andere probieren’s aus und finden, dass es bei der konkreten Testdatei gar noch leicht besser und leicht schneller war. So what?

Abgesehen davon kann xz mittlerweile sehr wohl Multithreading, wie oben schon geschrieben, und die einzigen mir aufgefallenen Unterschiede zwischen pixz und xz (neben den der paar Byte und Sekunden, die pixz besser/schneller war) sind, dass pixz Tarballs aufmachen kann, um das Komprimieren sinnvoll zu parallelisieren, und dass es keine hübsche Verboseoption mit fortlaufender Datenaktualisierung wie xz hat. Überhaupt spricht mich die Bedienung von xz mehr an, außerdem muss man zwei Zeichen weniger tippen, um’s zu benutzen. Und das ist ja wohl ein ein ultimatives Argument für xz. [scnr]

[wanne]

mit höchstmöglichem Kompressionslevel und schau’, wer‘s wie schnell bei wieviel RAM-Verbrauch wie klein macht.

Und genau diese Vorgehensweise wollte ich kritisieren. Multithreadded -9 ist in vielen Fällen eine deutlich schlechtere Idee als -8e mit einem Thread. (Langsamer bei schlechterer Kompressionsrate) Weil du mit deinen Tests eben nie alle Optionen abdecken kannst ist es durchaus sinnvoll mal zu gucken, was diejenigen, die das Tool geschrieben haben zu sagen haben.

[DeletedUserReAsG]

Hmm … steht denn die Zahl nicht mehr für die Kompressionsstufe? Wenn nämlich doch, dann ist die höchste Stufe die einzige Möglichkeit, verschiedene Programme sinnvoll zu vergleichen, „höchste“ ist überall „höchste“, aber -6 bei blubzip4 muss nicht -6 bei blar7 entsprechen (oder ist irgendwo festgelegt, dass die Option linear zu sein hat? Wenn ja, wo?). Hat dann selbstverständlich keine Aussage für die Geschwindigkeit, wenn man’s da vergleichbar machen wollte, müsste man die Parameter austüfteln, mit denen beide Programme etwa gleichstark komprimieren und dann die Laufzeit messen.

[heisenberg]

Und genau diese Vorgehensweise wollte ich kritisieren.

Danke für Deine konstruktive Kritik Wanne. Auch wenn in den Manpages normalerweise nur Müll drin steht, scheint es dieses Mal wohl anders zu sein. (Wer Ironie findet, darf sich gerne einen Stempel ins Hausaufgabenheft drücken lassen.)

Brute-Force-Testing ist für mich eine effektive Methode für den Erkenntnisgewinn.

Das viele Dateiformate mittlerweile eine sehr starke inhärente Kompression haben ist mir auch klar. Doch ich will nicht raten, sondern wissen(= testen). GIF bekommt man z. B. noch auf 65% runter.

Auch dass ich derzeit, wo ich noch in der Entwicklung des Testprogramms bin mit kleineren Dateigrössen spiele ist der Tatsache geschuldet, dass ich in überschaubaren Zeiträumen Ergebnisse haben will. Die Auswirkung auf pixz hatte ich dabei allerdings noch nicht so klar vor Augen.

Wenn ich noch genug Lust habe da weiter zu scripten, dann werde ich die Ergebnisse mal in eine kleine DB schreiben, um Dann die diversen Tests nur jeweils einmal (=1 x intensiv über X Einzelvorgänge) durchführen muss.

[wanne]

Die -1 bis -9 beeinflussen wie gesagt in erster Linie die DictSize. Garantiert die wichtigste Größe um die Kompressionsrate zu beeinflussen. Daneben gibt es aber eben noch einige andere:
Mehr Threads verursachen schlechtere Raten. Dann gibt es noch "mf", "mode" "nice" "lc"... xz bietet da viele Optionen.
Wenn du "depth" auf 9000 setzt, wirst du schlicht nicht mehr abwarten können bis das Ding fertig komprimiert.
Btw siht das bei gzip ähnlich aus -1 bis -9 stellen nur an einigen Parametern rum. Setzt man die in Sourcecode auf das maximum bekommt man wesentlich bessere Kompressionsergebnisse. Dafür komprimiert man an einem MiB über eine Minute.
Letztednlich ist eben auch -9 nur ein Kompromiss aus Geschwindigkeit und Kompressionsrate. Bei xz kannst du da mit vielen Parametern noch deutlich weiter jenseits des -9 gehen.
Irgend wann wird's halt sinnlos. Mit -9 zu vergleichen zeigt eigentlich nur, was die Entwickler des tools für die maximale noch vernünftige Datenrate hielten.

Entweder du hältst die Kompressionszeit konstant und vergleichst dann die Komprimierten Ergebnisse oder du hältst die Kompressionsrate gleich und guckst, welches am schnellsten ist.
Das maximum rausfinden zu wollen ist ziemlicher Quatsch. Irgend wann werden die Algorithmen halt so langsam, dass sie absolut unbrauchbar sind. Um das wirkliche maximum von xz herauszufinden bräuchtest du halt Jahre um deine ~200MiB zu komprimieren.

[wanne]

Brute-Force-Testing ist für mich eine effektive Methode für den Erkenntnisgewinn.

Dann mache bitte auch brute force und teste mit ALLEN möglichen Parametern:
dict=4,8,16,32,64,128,256,512,1024,2048,4096,8192,16384,32768,65536,131072,262144,524288,1048576,2097152
lc=0-4
lp=0-4
pb=0-4
mf=hc3,hc4,bt2,bt3,bt4
mode=normal,fast
nice=2-273
depth=1-10000

Und wenn du dann die 5328076800000000 Möglichkeiten durchprobiert hast, meldest du dich wieder.
Und dann überlegst du dir ob du für letzten paar Millionen Jahre wirklich eine effektive Methode zur Erkenntnisgewinnung genutzt hast.

bevor du das nicht gemacht hast, kannst du eben keinerlei aussagen treffen. Möglicherweise ist der Algorithmus ja schon gut nur du hast die falschen Parameter verwendet.

Ist wie wenn du feststellen willst, ob irgend etwas mit einem Algorithmus verschlüsselt ist. Bevor du nicht den letzten Schlüssel ausprobiert hast, kannst du nicht sagen, ob es der falsche Algorithmus oder nur der falsche Schlüssel war.

[heisenberg]

Dann mache bitte auch brute force und teste mit ALLEN möglichen Parametern

An Perfektionismus leide ich nur zu einem gewissen Grad. Die Tests sind ja kein Selbstzweck, sondern dienen dem Erkenntnisgewinn. Wenn sich bei manchen Parametern Auffälligkeiten ergeben, dann kann man da vielleicht ein paar Tests nachschieben. Aber ich brauch nicht wirklich alle 10.000 Optionen von irgend etwas durchzutesten und kann damit leben, wenn der 9.999ste den ich nicht getestet habe, das Ergebnis ist, wonach ich gesucht habe.

Wie Du, so habe auch ich die nächsten 10 Millionen Jahre schon was wichtigeres vor.

[Meillo]

OT:

Wie Du, so habe auch ich die nächsten 10 Millionen Jahre schon was wichtigeres vor.

Schade, dass wir solange auf euch zwei verzichten muessen ... aber nun gut, der Erkenntnisgewinn geht vor!

*SCNR*