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.
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(KOMPRESE(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.