Pravda, nicméně ta užitečnost stále pokulhává.
Kdysi jsem používal lz4, abych zrychlil přístup na disk u dočasných souborů a taky ušetřil trochu místa. Finální soubory šly do gzip na AWS S3. Nicméně paralelizace probíhala na vyšší úrovni - komprese věc zrychlí jenom v nějaké dnes už ne tak významné fázi.
Ten turbosqueeze IMHO v reálných podmínkách velký význam mít nebude a jeho komprese je oproti STORE relativně zanedbatelná (i ten lz4 vypadá teď slabě, ale záleží na datech - u XML či JSON je snad vyšší).
Ha, opravdu má, ale až od verze 1.10 z června 2024, takže to mám zatím jen v Gentoo. Podle všeho to pomáhá spíš při vyšší kompresi než při té nejrychlejší a dekompresi to pomáhá také trochu tím, že dá I/O do jiného vlákna než dekompresi. Zstd to má v podstatě stejně, však je stejný autor.
Tak jsem to zkusil a lz4 komprese na jednom vlákně mám 622MB/s a na čtyřech vláknech 722MB/s. U dekomprese se to prakticky neliší (taky jsem to psal do /dev/null) 1015MB/s a 1020MB/s.
Ten turbosqueeze neumím pustit na více vláknech :( Na jednom vlákně komprese má 256MB/s a dekomprese 818MB/s.
Já to mám v Debian 13 (+backports).
Rychlost s parametrem: -9
Jedno vlákno: 54 MiB/s
16 vláken: 365 MiB/s
Rychlost s parametrem: -12
Jedno vlákno: 47 MiB/s
16 vláken: 310 MiB/s
Tady to bylo bez parametru, což je výchozí rychlá komprese -1. Odpovídá mi i velikost komprimovaného souboru.