Vlákno názorů k článku
Komprese s více jádry procesoru
od anonym - Samozřejmě komprese a dekomprese využívající více CPU je...
-
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. -
PiViK (neregistrovaný)No, nevim jak s normalnimi daty, ale treba s videem jsem si to ozkousel dostkrat na bezstratovem kodeku Huffyuv, porovnani rychlosti komprese a dekomprese napr. zde: http://neuron2.net/www.math.berkeley.edu/benrg/huffyuv.html#Benchmarks
-
petík (neregistrovaný)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ě.
ČLÁNKY DO MAILU