#komprimace #gnu_linux
#Zstd je neskutečné dobrý #opensource komprimační algoritmus, měl by se víc propagovat (a používat).
Složky s webovým obsahem (HTML, CSS, obrázky atd.), celkem 220 Mb dat.
Jednovláknová komprimace do .tar.gz za 8 sekund a výsledek: 147 Mb.
Vícevláknová komprimace do .tar.gz za 1 sekundu (a taky 147 Mb).
Vícevláknová komprimace do .tar.zst za 1 sekundu a výsledek: 15 Mb (!!!)
GNU #gzip víc než 1 CPU nepodporuje, ale #pigz ano, který jsem použil pro porovnání rychlosti.
@amarok no, víc. V současnosti se používá jako defaultní na kompresi jak linux jádra tak třeba deb, RPM i arch balíčků a letos se začal použivat i na http kompresi. Je úplně všude, jen třeba není tak vidět jak starý páky jako gzip nebo xz 🙂
@mana_z
Debian používá pro repozitář (pokud vím) pořád ještě zejména XZ. U ostatních debianích derivátů nemám přehled. Každopádně dobře, že to použítí je už širší, jen mezi uživateli je to u bodu mrazu, zatím jsem si ani netroufl někomu poslat .tar.zst archiv 😀 A to ani lidem, o kterých vím, že používají Linux. Měl bych to možná brzo zkusit :)
@amarok dobře, koukám že Debian to nemá jako default, a zabudovanou podporu pro to má. Ubuntu a deriváty to jako default mají. Vidím to jako otázku času, jsou jako jedni z posledních. Už i RHEL to má 😀
@mana_z @amarok tož Debian.... :)
@The_ERROR
Aspoň známka toho, že v Debianu se víc hlasuje a neřídí to poloviční korporát typu Redhat nebo Ubuntu :) Tak snad od XZ k Zstd přejdou, i když mě jakožto příjemci updatů je to vcelku jedno, hlavně že se stahuje málo dat a je to bezpečné (po tom nedávném skandálu s XZ se snad dá XZ považovat opět za dostatečně kontrolovaný).
@mana_z
@amarok @The_ERROR v archu to byl celkem hezký úspěch. Nahodili tam na balíky zstd s drsnými flagy (--ultra -20) místo xz. Balíky se sice nepatrně nafoukly (0.8%) ale rozbalování bylo 13x rychlejší
https://archlinux.org/news/now-using-zstandard-instead-of-xz-for-package-compression/
Arch Linux - News: Now using Zstandard instead of xz for package compression

@mana_z
👍 Tak to je dost dobrý argument. Jen by mě teda zajímaly nároky na RAM při tom rozbalování, myslím teď třeba na nutnost updatovat OS na něčem minimalistickém jako Raspberry s 1Gb RAM.
@The_ERROR
@mana_z @The_ERROR
Jak jsem se ted docetl, tak v Debianu to je opravdu takove svobodnejsi ve smyslu, ze kazdy spravce baliku si muze rozhodnout, v cem to bude distribuovat. Narychlo jsem se koukal, skoro vsichni pouzivaji xz, mala cast je dokonce jeste v gzipu, a nenasel jsem narychlo ani jeden v zstd, i kdyz ta moznost teda uz je pres 5 let.
@amarok ale používat bych se to takhle asi nebál. gnu tar už to podporuje asi 5 let a libarchive možná ještě dýl 😀
@amarok Rychlost je jasná, ale takové rozdíly v kompresi rozhodně nedostávám. Rozdíl mívám tak do 5% gzip vs zstd ve prospěch zstd.🤷‍♂️
@smoon
Domnívám se, že Zstd (i XZ) musí mít něco jako tabulku s hashema zpracovávaných souborů, protože ten neskutečný rozdíl bude v mém testu daný tím, že se tam 360x opakuje spousta souborů, jen jsou v různých složkách. Možná se tomu odborně říká velikost slovníku a ne hashovací tabulka, každopádně v tom bude to jádro rozdílu. U gzipu jsem nepřišel na to, jak výrazně komprimační poměr zlepšit.
@amarok @smoon to je vlastně slovníkové kódování v kostce, co používají všechny tři. Akorát mě překvapuje že je v tom gzip tak špatný.
@mana_z @smoon
Já prakticky vím jenom jak funguje Huffman algoritmus, to jsem kdysi dávno použil pro můj úžasně inovativní (ehmm) komprimační prográmek v Pascalu 😄 Všechno ostatní je pro mě neznámá zóna, takže vůbec nedovedu posoudit nějakou technologickou podobnost mezi gzipem a zstd. U gzipu by velikost slovníku měla být při síle 9 logicky největší a ani tohle nepomohlo, takže jen tak tipuju, že to u Zstd budě neco podstatně rafinovanějšího než jen "look behind 128kb", ale ta rychlost?