Dobrý den,
když už je tu příprava na RAR 7.00, rád bych, aby bylo doplněno:
- "Uložit stejné soubory jako odkazy" (přepínač -oi). Bylo by dobré lépe nastavovat minimální velikost souborů, které lze porovnávat, např. -oi:50m . Nyní je nutné velikost vypsat v bajtech. Podobné něco i ve WinRARu v GUI. V GUI to nelze nastavit.
- Odebrání (neukládání) hashe hesla u šifrovaného archivu RAR5, který umožňuje mnohem rychlejší prolamování jak u RAR4 (z důvodu zpětné kompatibility jako volitelné).
Předem děkuji
Dobrý den,
zeptal jsem se na to a dám vědět
S pozdravem,
Ľubomír Mlích
Když už ER změnil SFX moduly na 64b jako výchozí, nebylo by dobré změnit i na Blake2 jako bezpečnější hash? Mám soubor, který v CRC zobrazuje 00000000 a nemá 0B. CRC dnes už nelze považovat za bezpečné.
Díky za dotaz,
zeptal jsem se ER, dám vědět až odpoví.
ER: Tuto změnu neplánuji, CRC je vcelku dobrý pro detekci neumyslných modifikaci dat.
S použitím Blake2 je sice menší pravděpodobnost kolize hash, avšak výsledný archiv bude větší než CRC. S ohledem na to, že tato pravděpodobnost je už dostatečně nízká u CRC, se mi tato volba nejeví tak zřejmá.
Porovnal jsem verze 6.24 a 7.00b2 s 32m a 256m slovníkem a zapnutou solid kompresí.
- špatně komprimovatelné soubory 30 % rychlejší u verze 7.00
- dobře komprimovatelné soubory 47 % pomalejší u verze 7.00
- o 1-5 % lepší komprese u verze 7.00
- verze 7.00 u 256m slovníku zabírá 2.3 GB RAM, verze 6.24 zabírá 1.6 GB
- verze 7.00 u 32m slovníku zabírá 302.6 MB RAM, verze 6.24 zabírá 435.9 MB RAM
- verze 7.00 je u 256m slovníku rychlejší o 10 % jak u 32m slovníku při špatně komprimovatelných souborech. U verze 6.24 je to naopak
- obě verze využívají cca 60 % CPU
Je tohle chování v pořádku?
>dobře komprimovatelné soubory 47 % pomalejší u verze 7.00
ER: Řekl bych, že to je příliš obecný závěr. Podívejme se na soubor enwik9 odtud: https://mattmahoney.net/dc/textdata.html Jedná se o textový soubor o velikosti 1 GB, který je dobře komprimovatelný.
Zde jsou mé výsledky na i9-12900K:
RAR 6.24 bez jakýchkoli přepínačů: 243 MB, 15,3 s
RAR 7,00 bez jakýchkoli přepínačů: 243 MB, 15,1 s
RAR 6.24 s přepínači -m5 -md1g: 227 MB, 64,8 s
RAR 7.00 s přepínači -m5 -md1g: 213 MB, 32,5 s
Zde je 7,00 ve výchozím režimu přibližně stejné a dvakrát rychlejší s lepší kompresí v režimu -m5 -md1g.
>verze 7.00 u 256m slovníku zabírá 2.3 GB RAM, verze 6.24 zabírá 1.6 GB
>verze 7.00 u 32m slovníku zabírá 302.6 MB RAM, verze 6.24 zabírá 435.9 MB RAM
ER: Lze jej ovládat volbou "Long range search" nebo přepínačem -mcl. Vypnutím snížíte využití paměti za cenu pomalejší a nižší komprese. Bude to přibližně stejné jako v 6.24, pokud je tato možnost vypnuta.
>verze 7.00 je u 256m slovníku rychlejší o 10 % jak u 32m slovníku při špatně komprimovatelných souborech. U verze 6.24 je to naopak
ER: Důvodem je, že "Long range search" je ve výchozím nastavení povoleno pro 256 MB slovník, ale ne pro 32 MB slovník.Zde je má tabulka https://workupload.com/file/8JpNRkMHLRJ
Testováno na i7-4790K. Celkově vychází verze 7.00 lépe.
To zpomalení je znatelné např. u písma (ttf, otf soubory)
ER: Testoval jsem to s *.ttf z c:\Windows a neviděl jsem žádný znatelný výkonnostní rozdíl. Možná se to stane s nějakým jiným *.ttf.
Drobné zpomalení v některých případech lze pravděpodobně vysvětlit relativně starým CPU i7-4790K. Potřeboval jsem použít příkaz pro zbytek z dělení v kompresním algoritmu 7.0. Představila drobnou penalizaci výkonu na i7-6700K, ale bez jakéhokoli zpomalení na novějších CPU jako AMD Zen 2 nebo Intel Alder Lake. Myslím, že výkon výpočtu zbytku dělení byl zlepšen v posledních rodinách CPU. Nicméně i na i7-4790K to vypadá obecně dobře.
Jeden z mých vzorků pro test: https://workupload.com/file/4bQvGtkKt8e
Je nutné mít zapnutou solid kompresi, aby se to projevilo.
ER: Ano, pokud nepoužíváme velký slovník v režimu „Nejlepší“, je pomalejší tento typ dat, ale poskytuje lepší kompresi. Pokud vypneme "long range search" pomocí přepínače -mcl-, kompresní poměr a rychlost budou mnohem blíže tomu v 6.24. Někdy může být "long range search" pomalejší než standardní vyhledávání, někdy je to rychlejší. Jeho účinnost je přímo úměrná velikosti slovníku. Také je efektivnější pro "Nejlepší" kompresní metodu než pro "Normální".
Zajímavá mi připadá ještě jedna věc: nárůst kompresního poměru díky většímu slovníku pro tento soubor dat.
RAR 6.24 s -s -m5 -md1g vytvořil 192978 KB archiv za dobu 65s. Je to to nejlepší, co může 6.24 udělat.
RAR 7.0 s -s -m5 -md1g vytvořil 185889 KB archiv za dobu 62s.
RAR 7.0 s -s -m5 -md4g vytvořil 134247 KB archiv po dobu 62 s.
A jako speciální bonus, pokud nám nezáleží na době komprese.
RAR 7.0 s -s -m5 -md4g -mcx vytvořil 127266 KB archiv pro 188s.
Dělal ER zmeny u -m1?
Použil jsem -m1, ostatní bylo výchozí nastavení a v některých případech je komprese horší až o 6% v porovnání s 6.24
ER: Ve výchozím nastavení pro -m1 byly vypnuty delta filtr a filtr pro spustitelné soubory. Pro -m1 je prioritou rychlost, kterou použití těchto filtrů mohlo znatelně snížit, cca 10 - 15% zpomalení, kvůli datové analýze, i u dat, kde není potřebná.
Vlastně ani vůbec neměly být pro -m1 zapnuty, ale přehlédl jsem to.
Filtry lze pořád zapnout pomocí přepínaču -mce -mcd
rar a -m1 -mcd -mce arcname
Při mých pokusech to má opačný efekt. Teď se čeká, až se zapíše větší archiv a to trvá déle, jak čtení.
U dobře komprimovatelných souborech je ten rozdíl výraznější.
Jak to myslíte ten opačný efekt?
m1 by měl být rychlejší s horší kompresí, takže vy vidíte zpomalení a zlepšení komprese?
Verze 7.00 s -m1 vytváří větší archivy v porovnání s 6.24 s -m1. Jak ER psal, vypnul u 7.00 filtry.
Zapsat větší archiv vyžaduje více času jak vyhodnocování souborů pro použití filtrů.
Příklad: 6.24 trvá vytvořit archiv 60s, to samé u 7.00 trvá 78s, protože vytvoří o 450 MB větší archiv z důvodu vypnutých filtrů. Oba mají stejné podmínky.
ER: Filtry mohou zvýšit rychlost pouze tehdy, když se s jejich pomocí zmenší velikost archivu. Ale u většiny datových typů nezlepší kompresní poměr a zároveň zabere čas analýza dat. Tato doba je patrná v režimu -m1, kde je celková komprese rychlá.
Například jsem zkomprimoval 4345 MB ISO obraz Windows 10.
Pokud použiji -m1, výsledný archiv je 4186 MB a doba komprese je 14,6s.
Pokud použiji -m1 -mcd -mce, výsledný archiv má 4184 MB a doba komprese je 17,3s.
18 % rozdílu rychlosti a 0,05 % rozdílu velikosti.
Zde je mé srovnání: https://workupload.com/file/7Rn7yQLq3yG
Příjde mi, že verze 6.24 je efektivnější.
Image Win10, kde je 95% souborů už komprimovaných, mi nepříjde jako ideální vzorek na test. Tam lze očekávat minimální rozdíl.
ER: Není mi jasné, co znamenají velikosti v prvním a třetím sloupci, jsou příliš rozdílné na to, aby to byly velikosti před a po zabalení
Každopádně vidím, že -m1 -mcd -mce je v těchto testech vždy, nebo skoro vždy, znatelně pomalejší než jen -m1. Pro metodu -m1 je prioritou rychlost komprese, kompresní poměr je až druhotným cílem.