Samozřejmě komprese a dekomprese využívající více CPU je pěkná věc. Mám ale za to, že kompatibilita je ve většině aplikací daleko důležitější, než kompresní poměr, nebo využití více CPU.
Pro informaci: co jsem takhle zkusil, tak Windows Explorer běží ZIPy na jednom CPU, a WinRAR balí RARy na dvou CPU (na 2-jádrovém CPU) a rozbaluje na jednom CPU (ovšem velmi rychle).
Já si naopak myslím, že kompatibilita nemusí být ta úplně nejdůležitější. To závisí případ od případu. Pokud využívám nějaký exotický kompresní algoritmus pro vlastní potřeby (archivace, denní zálohy), tak je to naprosto v pořádku. Kompatibilita se sebou samým je v tomto případě 100%ní. Ale máš pravdu v tom, že pokud jsou komprimována data určena někomu jinému, je třeba brát ohled na jeho možnosti dekomprimace.
K té druhé části Tvého příspěvku jen doplním. Je v zásadě můžeme rozdělit kompresní algoritmy na 2 skupiny. Ta první pomalu komprimuje, ale dekomprimace je relativně rychlá (zip, rar), takže je využívána k archivaci. Tzn. jednou spakuji, uložím na CD a pokud je potřeba jsem schopen se k datům rychle dostat. Komprimuji jednou - dekomprimuji mnohokrát.
Na druhé straně jsou algoritmy, které komprimuji relativně rychle, ale dekomprimace je zdlouhavá. Ta se vyžívá k zálohám (na pásky). Není příliš velká pravděpodobnost, že budu zálohu denně potřebovat, ale zálohovat se musí každý den. Komprimuji mnohokrát - dekomprimuji minimálně.
Tím chci říct, že nelze označit nějaký algoritmus za dobrý či vyloženě špatný, protože to závisí pouze na jeho aplikaci.
Ano, souhlasím. S tím, že kompatibilitu vidím jako důležitější. Není nic horšího, než když si někdo usmyslí posílat ostatním soubory v novém formátu, aby ušetřil pár procent na velikosti. Pochopitelně různé aplikace mají různé požadavky, a kompatibilita v konkrétním případě nemusí být rozhodující.
rar a zip jsou vhodné pro komprimaci na více procesorech, protože typicky komprimují více souborů a každý soubor je komprimován samostatně - výsledek lze potom poskládat.
gzip apod., které se používaje ve spojení s tarem oproti tomu všechno komprimují jako jeden soubor a tak rozdělení na více procesorů vyžaduje rozdělení vstupu na více "sektorů", které lze komprimovat nezávisle -> odtud plyne nekompatibilita - je nutno změnit formát.
Bylo by dobré, kdyby toto rozdělení na "sektory" se zapracovalo do standardního gzipu a bylo tak jen další verzí gzipu (ve standardní vývojové větvi) s možností vypnout v command-lině.