Porównanie: WinRAR - 7Zip - FreeARC oraz NanoZip

[cichy45 908]

Zawsze nurtowało mnie jaka jest różnica w możliwości kompresji plików przez różne archiwizatory. Trudno doszukać się takich testów więc sam wziąłem się do roboty i pokaże małe porównanie

 

Platforma testowa

:

CPU: Intel C2D E6550 2333 @ 3220MHz

RAM: 3Gb DDR2 800 @ 920MHz 5-5-5-18 T2

HDD: Patriot Pyro SE (lokalizacja kompresowanych plików) -> Samsung HD322GH (miejsce tworzenia archiwum)

MOBO: Asus P5Q Pro

PSU: Be quiet! Pure Power L7 530W

OS: Win7 - 64bit

 

Pliki testowe to katalog instalacyjny gry - dużo drobnych pliczków, część "kompresowalna" bardzo dobrze, część wcale. Kompresja była przeprowadzana w 5 trybach (odpowiednik w każdym programie): najszybsza, szybka, normalna, dobra, najlepsza.

 

No to jazda, na pierwszy ogień rusza każdemu chyba znany, dobry, poczciwy WinRAR

WinRAR jaki - każdy widzi, raz idzie mu lepiej za innym razem gorzej

 

Następny w kolejności to 7Zip, i kompresja LZMA2, ustawienia słownika/słowa - auto(domyślne dla każdego poziomu kompresji)

Z pewnością zadowala mniejszy rozmiar gotowego archiwum w przypadku najszybszej kompresji pomimo oczekiwania dłuższego o około 50 sekund.

 

3 już soft to FreeARC, program nie tak popularny jak dwa przed nim, lecz również nie oddaje pola bez walki.

Pomimo większego czasu kompresji w przypadku najmocniejszych ustawień, plik końcowy jest mniejszy od tego który stworzył WinRAR oraz 7Zip

 

I oto pora na ostatni program, wygrzebany z otchłani sieci - NanoZip. Program pracował ustawiony na 2 wątki oraz 2 kompresory pracujące jednocześnie. Użycie pamięci ram - standardowe.

Wyniki mówią same za siebie. W najszybszej kompresji jest skuteczniejszy od WinRAR'a oraz FreeARC'a, uzyskując mniejsze rozmiary archiwum. Jest od nich odpowiednio 3.9x oraz 1.2x raza szybszy. 7Zip co prawda jest w stanie bardziej skompresować pliki w najszybszym trybie, ale zajmuje mu to pięć razy więcej czasu. NanoZip uzyskuje również najmniejszy rozmiar archiwum w przypadku najmocniejszej kompresji(29.55% oryginału) ale osiąga to kosztem najdłuższego czasu pracy.

 

 

[cienislaw 0]

bardzo ładnie przygotowane!

 

a co do wniosków. RAR czasy świetności ma za sobą, co pokazują kolejne listy zmian, w których próżno szukać zmian w algorytmie kompresji. 7-zip nadal daje radę, ale jego apetyt na moc procka i pamięć na ustawieniach normal i wyższych jest ogromna, a jak pokazują wyniki dla tej konkretnej próbki testowej cokolwiek powyżej normal to strata czasu. FreeARC całkiem przyzwoicie, ale nie na tyle, żebym odwrócił się od 7-zipa. NanoZip mnie zaciekawił, szkoda tylko że na wyższych nastawach czas kompresji wzrasta kilkukrotnie, ale przynajmniej widać różnice w wielkości pliku wynikowego. to sprowadza się do jednego wniosku - o ile na potrzeby prywatne gdy ma ktoś czas można spróbować niepopularnych formatów kompresji, bo można zmniejszyć znacząco plik wynikowy, to w przypadku małych plików, które chcemy dalej dystrybuować szkoda na to czasu i lepiej zostać przy popularnych programach.

[Kerebron 0]

:thumbup:

 

Nie natknąłem się wcześniej na tego NanoZipa, potestuję.

 

Ciekawe jak w tym mini-teście wypadłby PeaZip?

[cichy45 908]

Dzięki za dobre słowo Planuję jeszcze test tych samych programów w kompresji 1, dużego pliku oraz zbadanie wpływu wykorzystania 1, 2, 3 oraz 4 wątków na czas kompresji pliku. Z oczywistych względów nie będę tego robił na swoim PC, lecz mam nadzieję że znajoma użyczy do tego eksperymentu jej PCta, opartego na Athlonie II 640

 

Co się tyczy PeaZip'a. Wiedziałem o programie już jakiś czas, jednak ze względu na dużą ilość czasu jaką trzeba poświęcić na przetestowanie tylko 4 programów, zdecydowałem że nie będę włączał do testu większej ilości. Być może zrobię uzupełnienie, dodając wspomnianego PeaZip'a oraz KGB Archiver'a

[pineko 0]

Bardzo fajny test Czas odejść od WinRara do archiwizacji plików. Nie sądziłem, że będzie taka słaba kompresja. Czekam na testy innych typów plików.

[cichy45 908]

Tym razem mam test pływu dołączania kolejnych rdzeni na szybkość kompresji pliku

 

Platforma testowa :

CPU: AMD Athlon II X4 640 3000MHz

RAM: 6Gb DDR3 1333MHz 9-9-9-24 2T

HDD: Verbatim Store 'n' Go 8Gb (odczyt 31Mb/s) (lokalizacja kompresowanych plików) -> Samsung 640Gb HDD (dokładna nazwa modelu nie znana miejsce tworzenia archiwum)

MOBO: Gigabyte GA-MA770T-UD3

PSU: Corsair CX500

OS: Win7 - 64bit

 

Wszystkie testy były wykonywane przy kompresji ustawionej na "Normalną". Użyty plik został wygenerowany w programie H2testw 1.4. Porównanie to nie ma na celu pokazania najszybszego/najskuteczniejszego programu, lecz tego który osiąga najwięcej korzyści z procesorów wielordzeniowych w badanym przypadku.

 

A więc po kolei jak poprzednim razem :

 

WinRAR:

Program działający na 1 wątku/rdzeniu poradził sobie z zadaniem w nieco ponad 2 minuty. Dołożenie kolejnego obniżyło czas o 35%. Działając na 3 wątkach program potrzebował 38% mniej czasu. Przy 4 wątkach oczekiwanie spadło aż o 43%.

 

7Zip:

Przy 2/3/4 wątkach zaoszczędziliśmy odpowiednio 53%/53%/70% czasu. Z pewnością zadowalający jest duży wzrost wydajności przy przejściu z jednego na 2 rdzenie. Niestety posiadacze procesorów trójrdzeniowych nie zyskają nic lub prawie nic(a przynajmniej nie podczas kompresji algorytmem LZMA2). Dopiero użytkownicy maszyn 4 rdzeniowych uzyskają dalszy spadek czasu kompresji.

 

FreeARC:

Wykorzystując 1 rdzeń program spakował plik w 31 sekund. Po obciążeniu 2 rdzenii czas spadł o 48%. Po przejściu na 3 rdzenie nastąpił spadek do 39%. Przy 4 wątkach program poradził sobie z zadaniem o 68% szybciej niż wtedy, gdy działał na 1.

 

NanoZip:

Działanie programu na 2 wątkach oznacza zakończenie kompresji o 41% szybciej niż w przypadku obciążenia 1 rdzenia. Po dodaniu 3 oraz 4 wątku otrzymujemy gotowe archiwum o 63% oraz 70% szybciej niż podczas pracy na 1.

 

Przy przejściu z 1 na 4 wątki największe procentowe skrócenie czasu kompresji zanotowały kolejno:

-7Zip/NanoZip (70%)/(70%)

-FreeARC (68%)

-WinRAR (43%)

[cienislaw 0]

pojawił się winrar 4.20 beta 1 i to co mówiłem o stagnacji zmian w kierunku lepszych osiągów mogę odszczekać. cały changelog można znaleźć tutaj, a interesujące nas zmiany przedstawiają się następująco

• zoptymalizowano algorytm kompresji ogólnej (uniwersalnej?) pod kątem lepszego użycia kilku rdzeni procesora
  
• wzrosła 3krotnie ilość pamięci niezbędnej do uzyskania wyższej szybkości kompresji (z 40 do 120MB)
  
• kompresja textu nie może zostać dostosowana, by efektywnie wykorzystywała więcej niż jeden rdzeń, dlatego domyślnie ją wyłączono
  
• tryb 'fastest" (-m1) robi użytek z kilku rdzeni (do 4.11 tylko jeden)
  
• poprawiła się szybkość dekompresowania danych, ale nie można w tym procesie używać kilku rdzeni
  
• kompresja ZIP również wykorzystuje kilka rdzeni procesora
  

 

@cichy45 - powtórzysz procedurę dla najnowszej bety? dzięki.

[cichy45 908]

Da się zrobić Jeszcze tylko muszę dokończyć testy kompresji 1 dużego pliku. A natrafiłem na taką sytuację że dla archiwizatorów to prawdziwe "piekło". Zresztą, zobaczycie sami

 

Trochę spóźniona odpowiedź, ale nie miałem dostępu jakiś czas do kompa(komunia u znajomych)

[cienislaw 0]

a ja mogę potwierdzić, że kompresja uniwersalna w przypadku plików tekstowych wypada gorzej, więc jeśli ktoś ma dużo takich plików do kompresji to warto ją włączyć.

[cichy45 908]

Zgodzie z obietnicą, czas na test programów w przypadku kompresji jednego pliku o dużym rozmiarze.

 

Plik został wygenerowany w programie H2testw 1.4. Dokładnie - program wygenerował 4 pliki o rozmiarze 1024Mb. Zostały one wrzucone do archiwum ZIP w trybie Storage, a więc bez żadnej kompresji. Następnie rozszerzenie pliku zostało zmienione, aby można go było ponownie spakować.

 

I jeszcze jedno słowo sprostowania. Nie wiem jakim algorytmem posługuje się H2Testw 1.4, lecz programy miały nie lada problem z kompresją pliku. Miała miejsce sytuacja gdzie po zastosowaniu mocniejszej kompresji... plik końcowy miał większy rozmiar niż w przypadku zastosowania szybszego algorytmu.

 

Platforma testowa:

CPU: Intel C2D E6550 2333 @ 3220MHz

RAM: 3Gb DDR2 800 @ 920MHz 5-5-5-18 T2

HDD: Patriot Pyro SE (lokalizacja kompresowanych plików) -> Samsung HD322GH (miejsce tworzenia archiwum)

MOBO: Asus P5Q Pro

PSU: Be quiet! Pure Power L7 530W

OS: Win7 - 64bit

 

WinRAR:

I oto mamy pierwszą anomalię. Kompresja szybka trwa dłużej niż normalna/dobra/najlepsza. I wyrzuca archiwum o minimalnie większym rozmiarze niż kompresja najszybsza. Za to 3 ostatnie metody skutkują tym samym rozmiarem pomimo wydłużającego się czasu oczekiwania.

 

7Zip:

Sytuacja podobna jak w przypadku poprzedniego programu. Wyjątkiem jest to, że większy plik powstaje na normalnym poziomie kompresji, a nie jak w przypadku WinRARa, szybkim.

 

FreeARC:

I po raz trzeci ta sama sytuacja... Mocniejsza kompresja skutkuje archiwum o większym rozmiarze. FreeARC najmocniej spakował plik z pośród wszystkich czterech testowanych programów, jednak zajęło mu to dobre kilkadziesiąt minut. Co ciekawe program dostał czkawki, i rozmiar pliku był większy nie tylko w przypadku Normalna vs. Szybka, ale również w przypadku Ultra vs. Wysoka.

 

NanoZIP:

Na usta aż ciśnie się powiedzenie: "tak dobrze żarło... i zdechło". Powtórka sytuacji z poprzednich 3 softów, mocniejsza kompresja = większe archiwum. Godzina poświęcona na spakowanie pliku najmocniejszym algorytmem skutkuje rozmiarem owego archiwum na poziomie 3.33Gb, co daje programowi ostatnie miejsce w tabeli najmocniejszych pakerów w tym przypadku. Widocznie pomimo zastosowania wielkiej ilości algorytmów kompresujących, czasami nie chcą ze sobą współgrać.

 

EDIT:

256 postów

[dr Bliss 0]

Plik został wygenerowany w programie H2testw 1.4. Dokładnie - program wygenerował 4 pliki o rozmiarze 1024Mb. Zostały one wrzucone do archiwum ZIP w trybie Storage, a więc bez żadnej kompresji. Następnie rozszerzenie pliku zostało zmienione, aby można go było ponownie spakować.

 

I jeszcze jedno słowo sprostowania. Nie wiem jakim algorytmem posługuje się H2Testw 1.4, lecz programy miały nie lada problem z kompresją pliku. Miała miejsce sytuacja gdzie po zastosowaniu mocniejszej kompresji... plik końcowy miał większy rozmiar niż w przypadku zastosowania szybszego algorytmu.

 

Stosujesz błędną metodę testowania - z założenia algorytmy stosowane w programach archiwizujących wykorzystują różne metody kodowania podobnych ciągów bitów, ale co do zasady wszystkie polegają na tym, że często występujące identyczne ciągi bitów są kodowane z użyciem krótkich ciągów binarnych (robi się taki słownik, że np. często występujący ciąg 00000010 będzie zapisany jako 01, itd.). Zgodnie z opisem na pierwszej lepszej stronie z tym programem, którego użyłeś: "Podczas testowania zapisu, program tworzy na wybranym urządzeniu pliki zawierające losowe ciągi znaków. ". Skoro te ciągi są losowe (a właściwie pseudolosowe o dużym okresie), to jest relatywnie mała szansa wystąpienia podobnych ciągów bitów. Stąd próba ich kompresji jest bezcelowa. Jest coś takiego jak "Zasada szufladkowa Dirichleta", która nawiązuje do sytuacji jaką spotykają algorytmy kompresji w przypadku danych pseudolosowych - nie da się opisać każdego ciągu binarnego o długości N lub mniejszej od N, ciągiem binarnym długości N-1 lub krótszym, a do tego dąży się w kompresji. Zauważ, że dla danych losowych uzyskasz dużo kompletnie różnych ciągów i to właśnie stanowi tutaj problem.

 

Tak poza tym fajnie, że komuś chciało się potestować te programy, bo ogólnie to bardzo czasochłonne jest... Spróbuj uwzględnić WinUHA (kiedyś to był dobry program, gdy trzeba było mocno upakować). A do testów stosuj raczej "rzeczywiste" dane, np. folder z dokumentami (doc i pdfy, maile), aplikacjami w tym grami (tu może być czasami problem, bo instalki gier zwykle są już mocno upakowane), to co zwykle ma się na dysku i chce spakować.

 

A poza tym polecam pobawić się packJPG w kontekście plików jpg (bez utraty jakości zmniejsza ich rozmiar).

[cichy45 908]

Hej dr Bliss. Dzięki za konstruktywną krytykę W takim razie podrzuć jakiś pomysł na plik (1 duży, co najmniej 2Gb) który mógłby być użyty w tym teście. Z własnego doświadczenia wiem że wszelakie pliki audio/video(poza formatami nieskompresowanymi) odpadają ze względu na to że już właśnie są skompresowane.

[cienislaw 0]

packJPG to całkiem ciekawy wynalazek - zachowuje i kompresuje nagłówek JPEGa ze wszystkimi niezbędnymi informacjami, dekompresuje JPEGa do raw lub innego formatu bitmpaty bez kompresji i pakuje go. daje to zdecydowanie lepszy rezultat niż typowe archiwizery, które nie stosują sztuczki z dekompresją bitmapy. średnio można przyjąć 25% zysku - tak mi wyszło po kilku na szybko skompresowanych zdjęciach 10Mpix. może któryś z archiwizerów kiedyś to zaimplementuje.

 

zrobiłem krótki test. obrazek 4MB zapisany w RAW 30MB w 2 sposobach (RGB RGB RGB, RRR GGG BBB) i pociągnięty rarem. packJPG z jpega zrobił 3MB, rar nie zszedł poniżej 11-12MB. wiem, że porównanie bez sensu bo packJPG powstał do jak najlepszego kompresowania konkretnego typu obrazków i na 101% wykorzystuje cechy budowy plików JPEG np makrobloki, ale to tylko potwierdza, że bez dedykowanych rozwiązań niektórych rzeczy nie da się lepiej skompresować niż oryginał (z sensownym zyskiem).

 

UHARC był popularny kilka lat temu, gdy wszystkie scenowe grupy używały go do tworzenia paczek z ripami gier... to dopiero było mistrzostwo. muzyka jeśli za dużo zajmowała była kompresowana do mp3, a w procesie instalacji depakowana do WAV i pakowana do formatu używanego przez grę. podobnie z teksturami. całość pociągnięta uharcem. i z jednego pliku robiło się kilka razy więcej danych;-)

[dr Bliss 0]

Hej dr Bliss. Dzięki za konstruktywną krytykę W takim razie podrzuć jakiś pomysł na plik (1 duży, co najmniej 2Gb) który mógłby być użyty w tym teście. Z własnego doświadczenia wiem że wszelakie pliki audio/video(poza formatami nieskompresowanymi) odpadają ze względu na to że już właśnie są skompresowane.

 

Wyjaśnij mi tylko, dlaczego chcesz koniecznie kompresować 1 duży plik?? TO ma być jakaś metoda przetestowania efektywności samego algorytmu kompresującego z wykluczeniem metod zarządzania plikami itp.?? Czy coś innego?

 

Duży plik, który nie zawiera losowych danych i z wyjątkiem niektórych sytuacji nie zawiera materiałów audio/video, jaki mi w tej chwili przychodzi na myśl, to plik pamięci wirtualnej. Można go wygenerować - najłatwiej na maszynie wirtualnej - ustawić jego duży rozmiar, a RAMu przydzielić mało np. 256MB i zapuścić Firefoxa na dużej ilości zakładek - wtedy 1,5GB raz dwa będzie... Albo ogólnie jakieś programy uruchamiać (tylko nie same graficzne, które będą bitmapy w pamięci przechowywać, bo to wtedy jak test kompresowanie plików bmp będzie).

Ilość danych rzeczywiście umieszczonych w pliku pamięci wirtualnej w XP można łatwo sprawdzić skryptem (w załączniku - trzeba usunąć z nazwy .txt i zostawić rozszerzenie vbs). W Windows 7 nie sprawdzałem działania skryptu (może potrzebować uprawnień administratora).

swap.vbs.txt