Zstd 1.5.0 s rychlejší a lepší kompresí

Ještě by bylo fajn napsat v kterém roce vyšel nejnovější procesor, který ještě neuměl SSE2. V roce 2016 jsem takový potkal, byl to nějaký 10 let starý stroj, který se válel v zadním rohu v kumbálu (serverovně). Všechny x86_64 processory SSE2 umí.

Spíš to bude otázka non-x86 mašin a mašinek...
Každodenně u x86(64) je to naprostá samozřejmost.

Pro jiné architektury existuje optimalizace taky. V podstatě jde o porovnání dvou vektorů. Na SSE2 se použije _mm_cmpeq_epi8, na ARM zase něco jiného (kombinace shift apod - vyžaduje o něco víc instrukcí, ale pořád mnohem rychlejší než porovnání po bytes). Až se rozšíří RISC-V (standardně s vector extension), tak určitě využijí i tam.

Zstd je naprosto skvělá komprese, vlastně používám už jenom ji (kromě vyložené archivace, kde používám xz).

Akorát je zvláštní, že na většině mých datech (různé jsony, kombinace hexadecimálního textu apod.) je zvláštní jev, kdy výchozí stupeň komprese (4) dává úplně nejhorší kompresní poměr. I menší stupeň komprese dává lepší kompresní poměr, a to čím dále od výchozí hodnoty, tím lepší.

Například teď jsem zkusil rychlý test na jednom ze souborů:

Komprese Velikost
1        5057067  <-- nejrychlejší, ale přitom super malé!
2        5147241
3        5407954
4        5589279  <-- největší velikost!
5        5445645
6        5323713
7        5141845
8        5028717
9+       (menší velikost)

Z prvních 7 stupňů nejlépe zabaluje ten první, nejrychlejší! Až stupeň 8 zabaluje lépe, ale zato mnohem pomaleji. Rychlost komprese je přitom očekávatelná, tedy snižuje se se zvyšujícím stupněm.

Takže já osobně zabaluju vždy na první stupeň, vyšší stupně nepoužívám vlastně vůbec.

To bude asi způsobeno zvláštností těch vstupních dat. Ale zstd umí i záporné rychlejší stupně, možná by stálo za to zkusit i je
zstd --fast=1

-1 je nejpomalejší, -2 rychlejší ...

Většinou komprimuji celé disky nebo partitions a tam mi hodně pomáhá pigz, který zvládá běžet vícevláknově a využije více jader CPU.

Je někde přehled, pro jaká data je zstd dobré a kde nic moc?

Souhlas, pigz je paradni a divim se, ze ty ostatni popularni kompresory paralelni processing neumi.

S pigz na Power9 s 64 lcpu (AIX, lpar, db server) zalohuji celou instanci databaze | pigz na 16 cpu a i kdyz je pod tim hw all flash diskove pole, ktere umi zapsat vysoke stovky MBs/s, tak diky te paralelni kompresi, kterou ta masina v klidu zvladne, snizim celkovy beh backupu na mensi polovinu, proste luxus a na pigz nenecham dopustit :-)

Tak zstd má třeba u mě na počítači rychlost obecně vyšší stovky MB za sekundu (podle obsahu), což stejně naráží na rychlost běžných disků.

Ale zase je fakt, že by to stejně mohlo umět i paralelní zpracování. Vlastně by bylo triviálně jednoduché udělat takové udělátko na paralelní kompresi nad jakýmkoli kompresorem. Využil bych toho, že všechny ty gzipy, xz, zstd apod. lze řetězit, (DEKOMPRESE(KOM­PRESE(obsahA) + KOMPRESE(obsahB)) = obsahA + obsahB). Takový kompresor by postupně četl soubor řekněme po 10 MB, každou takovou část zabalil v separátním vlákně, a pak všechny tyhle zabalené části postupně zapisoval do výsledného souboru. To by snad šlo i v bashi. Kompresní poměr by byl samozřejmě horší (mezi jednotlivými částmi se ztrácí kontext), ale to je u pigz taky, jinak to udělat ani snad nejde.

zstd je paralelní již nativně, lze použít buď zstd -T0, nebo zstdmt

xz taky umí paralelní kompresi xz -T0, nebo je k dispozici pxz

Tak to je docela zásadní informace. Díky za info.

Podle mě tam je nezanedbatelný prostor k optimalizacím.
Třeba sdílený slovník mezi vlákny.
Sekvenční přednačítání do paměti, aby se nečekalo až na to, které vlákno si řekne o jaká data.
Předstartovní analýza zdroje a vybrání vhodné strategie, jak ze zdroje číst.
....