Názory k článku Srovnání linuxových kompresorů dat: různé kompresní poměry a rychlost

Rad bych se zeptal - jakych konkretnich parametru techto programu /algoritmu se dane srovnani tyka?

Bez toho ta tabulka neni moc vypovidajici.

Edit: Urcite by stalo za to minimalne uvest, co z toho je default, co maximalni komprese a co maximalni rychlost (a, treba u xz, na tom zavisejici systemove zdroje, kde si dokaze u vyssich nastaveni vzit rameti opravdu hodne).

21. 11. 2024, 00:11 editováno autorem komentáře

Při hledání maximálního kompresní poměru byly použity tyto parametry:

declare -A A=(
    [lz4]="-fk -12 -c"
    [lzop]="-fk -9 -c"
    [x]="-fk -9"
    [gzip]="-fk --best -c"
    [bzip2]="-fk -9 -c"
    [xz]="-fk -9 -e -c"
    [lzma]="-fk -9 -e -c"
    [zstd]="-fk --ultra -22 -c"
    [brotli]="-fk -q 11 -c"
    [bzip3]="-fk -c"
    [zopfli]="--i1000 -c"
    [lzop]="-fk -9 -c"
)

Při zaměření na rychlost komprese:

declare -A A=(
    [lz4]="-fk -1 -c"
    [lzop]="-fk -1 -c"
    [x]="-fk -9"
    [gzip]="-fk --fast -c"
    [bzip2]="-fk --fast -c"
    [xz]="-fk -0 -e -c"
    [lzma]="-fk -0 -e -c"
    [zstd]="-fk --fast -c"
    [brotli]="-fk -q 0 -c"
    [bzip3]="-fk -c"
)

Jsou tu kusy bashových skriptů.

Tak všude máte jiné parametry pro maximální rychlost a maximální kompresi kromě bzip3. Ten bzip3 má parametr -b: Set the block size to N mebibytes. The minimum is 1MiB, the maximum is 511MiB.

Výchozí hodnota je 16. Menší je rychlejší a větší zase větší komprese a spotřeba RAM.

Možná by pak v rychlosti nevycházel tak blbě jako starý zpaq. Na rozdíl od zpaq a bzip2 umí bzpi3 více vláken.

Věřte, že jsem ten parametr -b důkladně vyzkoušel. Bohužel v datasetu se vyskytují jen soubory pod 10 MiB. Takže zvětšování té výchozí hodnoty vůbec nic nepřinese.

Dobře, ale co zmenšování pro větší rychlost do tabulky rychlosti (-b 1)?

Když jde o rychlost dekomprese, tak mě zaujalo spíš toto:

https://sneller.ai/blog/decompressing-at-over-10-gigabytes-per-second/

Podle toho grafu je Iguana mnohem rychlejší než LZ4 a má ještě lepší kompresní poměr. Nechybí ani srovnání s Zstd s použitím aritmetického kódování (kompresní poměr srovnatelný a skoro 3x rychlejší při dekompresi). Nepíšou tam ale rychlost komprese, takže to asi nebude nic moc.

Na druhou stranu je očividné, že LZ4 už nemá prvenství v rychlosti dekomprese.

Škoda, že v porovnání chybí rar - oproti ostatním algoritmům umožňuje navíc přidávat data pro obnovu v případě poškození...

RAR chybí v popisu algoritmů/nástrojů, ale tabulkách s výsledky je uveden.

Data pro opravu umí vytvořit par2 naprosto univerzálně k čemukoli, jen to dneska už není taková nutnost jako v dobách disket a cd.

> Zstd běžně dosahuje podobných kompresních poměrů jako Deflate, ale za to je rychlejší. Při maximální kompresi dosahuje Zstd kompresních poměru blízko LZMA.

Podle tabulky to tak nevypadá - Zstd obvykle bývá účinnější i při default level.

Škoda, že chybí jako příklad JSON - dnes prakticky nejpoužívanější formát - Zstd běžně dosahuje 5-10% původní velikosti.

Kdysi jsme vyvíjeli proces zpracovávající velké množství dat. Pro lokální kompresi jsme použili LZ4 kvůli rychlosti, pro finální úložiště Gzip. Zstd tehdy ještě nebyl na světě, ale dneska by to byla jasná volba.

json bude mít kompresní poměr skoro stejný jako xml - jsou to textová data

Možná ne, XML je strašně ukecané a má párové značky, stejný text blízko sebe.

Ukecanost xml nemá absolutně žádný vliv na kompresní poměr. Jména tagů i atributů se budou opakovat, takže to je pro kompresní algoritmy naprosto optimální.

Asi narážíš na to, že do 1 MB xml se "vejde" méně surových dat, než do json.
Vliv na kompresní poměr bude zanedbatelný.

Jména tagů i atributů se budou opakovat, takže to je pro kompresní algoritmy naprosto optimální.

Coz znamena, ze kompresni pomer bude vyssi.

Ahoj, díky za inspiraci, ale ja to asi nechapu.

Vzdyt se porovnavaji hrusky z jablkama.
Na jedne strane mame tabulku s maximalni kompresi a na druhe strane s maximalni rychlosti. Nad slunce je ale jasne ze nejde mit oboje.

Teda bylo by treba k maximalni rychlosti komprese doplnit kompresni pomer.
A naopak k maximalnimu kompresnimu pomeru cas pro kompresi.

Jinak nejde nic rozhodnout. Ta nastaveni mezi softy jsou prece tak siroka a nekonzistentni.

Původně jsem tam měl i ty dvě tabulky, které Vám chybí, ale pak jsem je smazal, protože neměly smysl. Když někdo cílí na maximální kompresní poměr, logicky ho nezajímá rychlost (je jasné, že si bude muset dlouho počkat). Když naopak někdo cílí na rychlost komprese, nebude ho ani moc zajímat dosažený kompresní poměr (bude ho zajímat ta rychlost). Nicméně všechno by se dalo vynést do grafu závislosti kompresního poměru na rychlosti komprese. Já jsem zvolil tabulky, protože mně to přijde přehlednější (přece jenom nejlepší hodnotu zvýrazníte tučně a vypadá to dobře).

To si dovolim oponovat, kdyz jsme to neco nejen naposledy resili, tak vzdycky bylo zadani "kompresni pomer co nejlepsi pri takovem nastaveni, aby se ty zalohy stacily zabalit do dalsiho dne" (+samozrejme velka rezerva v sizingu na rostouci data, ...)
Pripadne k tomu primerena rychlost dekomprese.

(coz, mimochodem, vyradilo maximalni kompresi na xz - je fuk, jestli kazdodenni job bezi 10 minut nebo 2 hodiny, ale kdyz to vychazi na 25 hodin, tak se musi udelat kompromis)

Chápu. Příště udělám podobné srovnání s grafy. Něco jako zde.

Díky, to by moc pomohlo!

Ono je zajímavé oboje. Tak jak to je teď, tak v první tabulce je maximální výkon, ve druhé pak minimální cena. To je zajímavá informace. Pokud si člověk chce udělat ještě navíc představu o poměru cena/výkon, tak ale už nemá šanci.

Já bych se za to taky přimlouval (mimochodem i tak díky za článek!). Možná by bylo zajímavé i zahrnout polemiku o tom, jaký algoritmus je v praxi vhodný pro určité použití (např. zahrnout rychlost komprese vs. účinnost vs. rychlost dekomprese a podle různých vah těchto faktorů stanovit výsledné skóre). A třeba mě by i zajímala nějaká "zlatá střední cesta", řekněme ve smyslu algoritmus/kom­presní poměr/rychlost komprese/konkrétní nastavení daného nástroje, byť je asi hodně těžké něco takového rozumně definovat.

EDIT: A ještě dodatek - v článku je uvedeno, že testy byly prováděny s omezením na jedno vlákno, což určitě pro základní porovnání dává smysl. Na druhou stranu v době dnešních vícejádrových procesorů by bylo zajímavé do porovnání zahrnout i výkon při více vláknech.

21. 11. 2024, 12:49 editováno autorem komentáře

Diky moc, to je presne ono, co mi tolikrat chybelo a co spouste lidem usetri hodne casu a nervu. :-)

Určitě by bylo dobré si říct, jaká je nejlepší možná komprese při které výstup vytěžuje 100, 1000 či 10 000 Mbps linku na maximum a jaké je při tom vytížení procesorového jádra.

Zálohy jsou záludné ze dvou důvodů, řada systémů jede non-stop a kromě režie (do které zálohy spadají) dělají i užitečnou práci. On je dobrý důvod, proč ZFS standardně používá LZ4 a hodně adminů přechází na ZSTD. Kromě early abort při špatné kompresibilitě a vysoká rychlost a slušná učinnost hlavně u ZSTD z těchto algoritmů dělá dobré kandidáty na většinu nasazení, kde nejsme v nějaké krajní poloze (např. nějaké deep archive nasazení, nebo velká limitace propustností).

Když naopak někdo cílí na rychlost komprese, nebude ho ani moc zajímat dosažený kompresní poměr (bude ho zajímat ta rychlost).

Keď niekoho zaujíma len rýchlosť, tak bude predsa dáta ukladať bez kompresie.

za zmínku taky stojí lrzip, i když to je spíš prekompressor, pro velké složky (předevšim pro ty které mély několik vezí těch samých souborů) fakt pomohl, lrzip potom má věstavený lzo, gzip, bzip2, a zpaq, ale nechá se kombinovat se vším.
Zstd by mělo mít něco jako lrzip ale nevim jistě.

21. 11. 2024, 07:27 editováno autorem komentáře

Diky za clanek, ale ty tabulky jsou dost tezkopadny. Narychlo vygenerovane grafy v google sheets -> https://imgur.com/a/sUbgTAZ

U jakehokoliv srovnani kompresoru dat se nejde zavdecit vsem. Standardni testovaci data pro kompresi jako odkazovany Silesia compression corpus jsou obvykle obsolete (ne, skutecne nikdo nekomprimuje Tarred executables of Mozilla 1.0 (Tru64 UNIX edition)) a obsahuji male mnozstvi dat (200MB?) a mnozstvi parametru jednotlivych kompresoru ovlyvnuje vyslednou spotrebu RAM. Dnesni uzivatel komprimuje obvykle zdrojaky, dokumenty (office/pdf), obrazky, videa, executables. No a nekdo ma 8GB RAM a tudiz nemuze vyuzit vsechny optimalizace ktere treba vyzaduji 128GB RAM (nebo klidne 1TB RAM) a kompresni pomer diky velike RAM muze byt klidne 2x lepsi. Clanek presto ocenuji.

Pěkný článek. A mám rovnou námět na další :) Pokud se jedná o srovnání kompresorů (což chápu jako "softwarových nástrojů") a ne jednotlivých algoritmů, tak by imho dávalo smysl i srovnání vícevláknových běhů. V dnešní době by to víc odpovídalo reálnému nasazení a pokud jej nástroj umí využít, je to jeho výhoda.

21. 11. 2024, 12:23 editováno autorem komentáře

Uz to, ze autor primo v clanku neuvadi kompresni level pro zvolene kompresory bylo varovanim. Ze zvedavosti jsem ten bzip3 i zpaq zkusil na komprimaci 100mb zdrojaku a oproti xz na vysokem kompresnim levelu se to dle ocekavani nechyta (byt je xz samozrejme pomale).

Zajimavejsi zpusob porovnani je dle meho soudu udelat par 2D grafu, kde je na x-ose kompresni level a na y-ove ose velikost/casy pro kompresi/dekom­presi, pripadne paralelizovane verze.

Tak se clovek vyhne absolutnimu porovani, a misto toho vidi jasny trade-off mezi casem, ktery je ochoten tem algoritmum dat a vyslednou velikosti. A podle dane aplikace vybere, ktery kompresor (*a na kterem levelu*) je pro danou situaci nejlepsi.

Můžete vysvětlit, co znamená „se nechyta“? Nejlépe nasdílet ten „100mb zdrojak“, ať to můžu taky porovnat.

Ty kompresní parametry máte nahoře v diskuzi.

Tak jde použít třeba linux-6.12.tar.xz. Zajímavé je, že kernel.org používá zřejmě -7. S -9 -e je to ještě menší. Asi šetří elektřinu a bandwidth mají dost.

Tak tady jsou výsledky na linux-6.12.tar:

1,5G linux-6.12.tar
140M linux-6.12.tar.bz3
134M linux-6.12.tar.xz
100M linux-6.12.tar.zpaq

Tedy xz bylo o 4 % lepší něž bzip3, ale celé to zabil zpaq, který byl o 34 % než právě to xz. To je konzistentní se závěry článku.

I stand corrected! Nenasel jsem pri rychlem prujezdu manualovych stranek pro zpaq nastaveni pro nejvyssi kompresni level. Ted jsem nasel -m5 a skutecne to xz pri tomto levelu prekonava.
Omlouvam se za vypad, explicitni parametry v clanku tomu mohly zabranit ;)

brotli má vnitřní statický slovník (120kB), zaměřený na kompresi webu. Slovník se nemusí posílat s komprimovanými daty.

zstd i brotli umí použít uživatelský slovník, natrénovaný na konkrétních souborech.

Od chvíle, co jsem objevil zstd, už tyhle věci vůbec neřeším - podle úrovně to umí i superrychou i velmi efektivní kompresi, takže většinou akorát volím level a na všechno používám zstd.

Neopomenul se 7zip? Já to nikdy neporovnával, používám ho kvůli možnosti šifrování. Což mi vyšlo o dost rychlejší, než kombinace, byť si nepamatuji jaká ... Rozhodně jsem toho nezkoušel tolik.

7zip muze mit vevnitr LZMA/LZMA2/bz­ip2/gzip/PPMd. Takze jedine co tam chybi je ten PPMd...

PPMd umí RAR, ale musí se explicitně zapnout.

7Zip je LZMA a je uveden.

To skoro vypadá jako chlubeni se počtem.jader.. ale aspoň vidina že pokračování zapojí multithreading

Mezi generickymi kompresnimi algoritmy je uz deset let jasna jednicka. Zstd je jasna volba prakticky pro vse. Umi komprimovat rychle i kvalitne (podle nastaveni). Navic veci jako

dictionary (i kdyz, pozor ty jsou asi jeste porad mizerne)

long range (jako lrzip)

adaptive compression (pro saturovani linky s omezenou rychlosti)

patch-from nebo rsyncable jsou take skvele a jinde nepodporovane

Za zminku stoji i dobre api. Tedy pokud ma nekdo rad C :) Daji se s nim delat veci lepsi nez s cimkoliv jinym.

Vyjimecne se jeste hodi neco hodne rychleno a maleho co se vejde do L1 cache. V tom pripade lz4, take od Yanna Colleta :)

Zstd nejvice testovane a nejvic adoptovane. Takze je spis otazka proc psat dalsi benchmark / clanek?

Kdyz uz clanek - tak jak uz bylo v komentarich zmineno - byly by pekne grafy jako http://quixdb.github.io/squash-benchmark/. Pokud nekoho zajima exotika jako zpaq pak je tu samozrejme https://www.mattmahoney.net/dc/text.html

Kazdopadne by to chtelo konzistentni parametry mezi grafy a tabulkami. Vice (ale ne vsechny) nastaveni (compresni level atd). Take je potreba zahrnout spotrebu pameti. Ale jeste pred tim naprosto nezbytne vzit modernejsi (a vetsi) dataset.

BTW: Testovat rychle kompresory jako lz4 v shell scriptu neni idealni. Zejmena na malych souborech prakticky nemozne. Take jsem to zkousel ;-) Ale jen forknuti procesu a nacteni binarky nebo io potrebuje vic casu nez samotna komprese / dekomprese. Jinak by i ten 6 let stary procesor zvladal nekolik GB/s.