Vlákno názorů k článku
Fwupd přechází z XZ na Zstd, kromě důvěry získá také lepší kompresi od Michal Smrž - 579138 output.xml20304 output.xml.xz -z9e21617 output.xml.zst -22 --ultra Nevím...

579138 output.xml
20304 output.xml.xz -z9e
21617 output.xml.zst -22 --ultra

Nevím jak testovali, u mě xz poráží jen zpaq se strašnými nároky. A to zstd na té maximální kompresi bylo rozhodně pomalejší.

Jste si jist, že použíají maximální kompresi? Zstandard 22 je extra pomalý. V podstatě od cca 13 dál silně roste náročnost ale efektivita se už skoro nijak výrazně nezvyšuje. U XZ to ostatně není o moc jiné. Nelze to porovnávat tímhle způsobem.

Tak nějak jsem čekal, že soubor, co je potřeba distribuovat milionkrát denně z CDN bude komprimován, co to jde. Proti rychlosti zstd nemám nic, ale xz je na archivaci stále lepší.

U malých souborů to je sice pravda, ale to nic nemění na tom, co jsem napsal. A jinak xz lepší pro archivaci... ono si docela rozmyslíte, jestli budete mít s xz 9 o 5 % menší soubor co se bude komprimovat desetkrát pomaleji než zstd 11 když ten soubor má třeba deset GB. Tolik k té archivaci. Zlaté zstd.

Pomalejší při kompresi nebo dekompresi? OP píše o dekompresi. U mě (podle hyperfine) trval jeden zstd -d 6.5 ms, zatímco xz -d 32 ms.

Co se velikosti týče, zřejmě ve srovnání nepoužili xz --extreme, který má své mouchy (není deterministický a někdy paradoxně zvětší výsledný soubor). Ale i s ním mi vychází zstd o pár % lépe,

664Ki firmware.xml.xz
652Ki firmware.xml.zst

(testováno s dnešním fwupd firmware.xml).

3. 4. 2024, 19:07 editováno autorem komentáře

Je to hezké, ale v jakých případech vás donutí použít zstd oproti xz, aby jste získal ten blaženej výkon?

Jaderné moduly a firmware jsou komprimovány zstd právě kvůli "blaženému výkonu" při dekompresi, IIRC byly to nějaké vyšší jednotky sekund rozdílu v délce bootování distribučního archlinux jádra oproti xz.

U storage reseni je zstd vyhodne treba u slabe storage site pokud mate na pripojenem LUNu komprimovany filesystem.

[Jakub Štech]

Ja osobne pouzivam xz (lzma) na tvoru samospustitelnych archivu (vyuzivam je na automaticke spousteni, konfiguraci a spravu dat hlavne pro hry spooustene pod dosboxem a vyjmecne i ve wine). Lzma zabere sice vyce casu pro komporesy, ale dekomprese je pomerne hodne rychla. Navic ma docela slusny kompresni vykon. To vsechno beru jako rozumne vlastnosti a cenu pro moje potreby.

Pod vlivem jednoho z clanku zrovna tady na rootu jsem otestoval i vyuziti Zstd ( konkretne se jednalo o slavny Duke Nukem 3D Atomic Edition) a jako nadseni zadny. Pomerne mnoho casu jak na kompresy, tak i na dekompresy a vysledny balik nebyl ani nijak moc vyzname mensi nez s xz. Dalsi velky problem bylo hlidani si specifickych argumentu, ktere bylo nutno pri maximalni kompresy zadat Zstd pro dekompresy archivu (coz vedlo k vetsi slozitosti dekompresniho skriptu oproti predchozim variantam a nutnosti ukladat specificke zaznami o kompresnich paramtrech, nebo s nimi generovat dekompresni skript. Proste o rad vyssi komplexita. nic co by se mi libilo)

Takze jsem nakonec vyhodnotil (prozatim), ze mi Zstd za tu namahu nestoji. Aneb jak by se kulatne napisalo ve vedeckych kruzich: "Vyhody Zstd se mi nepodarilo prokazat. Je potreba dalsiho vyzkumu..."

6. 4. 2024, 13:15 editováno autorem komentáře

Specifických parametrů? Jakých? A xz je oproti zstd pomalé úplně brutálně. Proto ho taky zstd na mnoha místech nahrazuje.