Kompresja na cztery fajerki

14 lutego 2008

Linux.com prezentuje dwa programy, które pomagają wyciągnąć z procesora więcej mocy przy kompresji plików .gz i .bz2. Ta technika dotyczy jednak tylko posiadaczy procesorów wielordzeniowych.

Jak łatwo sie domyśleć, chodzi o zaprzęgnięcie do pracy równoległej wszystkich dostępnych rdzeni. Program mgzip obsługuje jedynie kompresję (nie przyspieszy zatem dekompresji), natomiast pbzip2 obsługuje zarówno kompresję jak i dekompresję, ale przyspiesza rozpakowywanie tylko plików .bz2 stworzonych przez siebie.

Koszt to tylko nieco większe pliki po kompresji (o niecały 1% w przypadku pbzip2), a oszczędność czasu jest wyraźna: przy 4 rdzeniach zyskamy około 3-krotne przyspieszenie pracy.

PODOBNE WPISY:

żadnych reklam, sama wiedza.

Zarejestruj się na BEZPŁATNY NEWSLETTER i raz w tygodniu otrzymuj najważniejsze wiadmości
ze świata IT, nowych technologii i kryptowalut.

Bez reklam.

Zarejestruj się za darmo

Technologie

19 odpowiedzi na „Kompresja na cztery fajerki”

SlashBeast

15 lutego 2008

pbzip2 uzywam od pewnego czasu, brak mi natomiast cos takiego do lzma, w stylu plzma.

Odpowiedz
1. Karl
  
  15 lutego 2008
  
  Hmm.. Do LZMA to jest 7-zip który umie obsługiwać więcej niż jeden rdzeń, tylko wymogi co do RAMu ma spore 🙂 Maksymalna kompresja (-ms=on, mx=9) 1 GB tara z pocztą na 1 GB RAMu to zły pomysł (czytaj: za mało RAMu!).
  
  Odpowiedz
2. zuzia
  
  15 lutego 2008
  
  lzma obsługuje wielowątkowość, w odpowiednio nowej wersji.
  
  Odpowiedz
3. pdemb
  
  15 lutego 2008
  
  Z tego, co wiem, to najlepsze pod względem stopnia kompresji są teraz programy oparte na algorytmach PAQ.
  
  Odpowiedz
Camelek.AmigaRulez

15 lutego 2008

Nie łatwiej byłoby, gdyby ktoś podzielił gzib/bzip2 na wątki?
Wydaje mi się, że to byłoby rozwiązaniem :]
Najlepiej to widać w przypadku Blender'a :]
Jeśli posiadacie procesor wielordzeniowy, to uruchomcie renderowanie w jednym procesie, a następnie spróbujcie w dwu, lub większej liczbie :]
Czas się skraca do około połowy :]

Odpowiedz
1. wojtekm
  
  15 lutego 2008
  
  Tylko wówczas każdy wątek musiał by tworzyć własny słownik (mniejsze upakowanie danych), bo w przeciwnym przypadku po pierwsze spadała by wydajność przez wzajemne blokowanie wątków na dostępie do słownika, a po drugie zaczęła by się z niego robić kasza, bo każdy by wprowadzał losowe modyfikacje na własne potrzeby (dodatkowy spadek efektywności, może być duży lub mały, to zależy od strumienia danych wejściowych).
  
  Blender i generalnie rendering to inna bajka, bo tam jak się już zrobi drzewo BST reprezentujące scenę, to każdy wątek może sobie je przeglądać do woli bez konieczności jego modyfikacji i robić swoje.
  
  Nie wszystko się tak łatwo zrównolegla, akurat kompresja ze swej natury jest jednowątkowa, jej zrównoleglenie wiąże się ze spadkiem jej efektywności.
  
  Odpowiedz
socrtp

15 lutego 2008

Pytanie tylko – po co się babrać bzip2, skoro jest LZMA i na ile pamiętam obsługuję wątki? Z pamięci – LZMA jest nieznacznie wolniejszy od gzipa, a kompresuje lepiej niż niesamowicie powolny bzip2.

Odpowiedz
1. emiles
  
  15 lutego 2008
  
  A co rozumiesz pod pojęciem "trochę wolniejszy"?
  
  Zachęcony Twoim komentarzem zrobiłem mały teścik:
  
  Kompresja pliku PostScript 88,5MB (dokładnie 90740631B)
  na jednym rdzeniu.
  
  gzip – 22 MB, 9 sekund
  lzma – 17 MB, 105 sekund!!!
  
  Czy to jest "trochę" wolniej?
  Test powtórzony kilkakrotnie, wyniki uśrednione, ale rozrzut czasu był
  na poziomie 1%
  
  Może ja coś źle robię? Używałem gzipa i 7z z pakietu p7zip bez żadnych dodatkowych opcji.
  
  Odpowiedz
  1. socrtp
    
    15 lutego 2008
    
    faktycznie, o poranku nie wyraziłem się jasno 😉 ja kiedyś testowałem LZMA z Gentoo (konkretnie app-arch/lzma) i parę rzeczy mi wyleciało już z głowy 😉
    
    nie miałem czasu robić większych benchmarków, proponuję obejrzeć:
    http://tukaani.org/lzma/benchmarks
    
    czasy kompresji nie są dobre dla większego stopnia kompresji, jednak stopień 1 odpowiada mniej więcej rozmiarowo bzip2 -9 (zależy od danych), jest od niego szybszy i moim zdaniem jest to bardzo sensowna alternatywa dla bzip2.
    
    natomiast rano miałem na myśli czas dekompresji. zdarza się, że trzeba trzymać duuużo spakowanych danych i często je rozpakowywać. wszystko ładnie widać pod w/w linkiem. dekompresja średnio 3x wolniejsza niż gzip, natomiast 3 do 5 razy szybsza niż danych spakowanych bzip2 -9
    
    ciekawe jest też to, że dekompresja bzipa jest tym wolniejsza im większy stopień kompresji pliku był zastosowany.
    
    Odpowiedz
SlashBeast

15 lutego 2008

Nie interesuje mnie p7zip, jedynie czyste lzma. To, że 7zip używa algorytmu lzma nie oznacza, że jest z nim zgodny.

Odpowiedz
robert

15 lutego 2008

Dla mnie czas kompresji nigdy nie był krytyczny (używam zwykle gzip-a) i wątpię, czy istnieje zastosowanie (zwłaszcza komercyjne), w którym skrócenie czasu kompresji przełoży się na jakieś znaczące zyski. Trzeba przyznać, że wyniki osiągnęli niezłe, ale dla człowieka nawet 3-krotne przyśpieszenie procesu ,który trwa zaledwie 45 sekund, ma niewielkie znaczenie.

Odpowiedz
1. soal
  
  15 lutego 2008
  
  Wszystko fajnie, ale LZMA jest kompresorem strumieniowym w przeciwieństwie do BZIP2 – jeśli nagra się CD/DVD z plikiem skompresowanym strumieniowo, to będzie ciężko odzyskać z niego dane w przypadku zarysowania płyty (błędy CRC, itp.) – natomiast BZIP2 kompresuje blokowo, dlatego większość plików w takich archiwum da się odzyskać z uszkodzonej płyty.
  
  Odpowiedz
  1. soal
    
    15 lutego 2008
    
    Chodziło mi o *CD/DVD z plikami skompresowanymi strumieniowo (…)
    
    Odpowiedz
2. kocio
  
  15 lutego 2008
  
  Zależy jak dużo się pakuje. Serwery typu builder i menedżery pakietów (zwłaszcza podczas instalacji systemu, kiedy instaluje się wiele pakietów na raz) mogłyby na tym skorzystać — w końcu pakiety są standardowo pakowane.
  
  Odpowiedz
  1. robert
    
    15 lutego 2008
    
    Nie przeczę, tylko zysk będzie znikomy. Większość czasu zajmuje kompilacja, linkowanie, testy regresyjne oraz pobieranie pakietu przez sieć.
    
    Odpowiedz
    1. kocio
      
      15 lutego 2008
      
      Pewnie masz rację. W każdym razie standardowa instalacja paczek z płytki (kopiowanie plików żywcem z LiveCD oczywiście nie) byłaby MSZ wystarczającym uzasadnieniem dla pakietów, którym da się skrócić czas dekompresji.
      
      Wie ktoś jakie dystrybucje korzystają obecnie z pakietów pakowanych bzip2? Nie mogłem się doszukać jak to jest w Ubuntu (zdaje się że tylko dokumentacja?), ale kiedyś chyba Mandriva to rozważała. Zresztą ciekawe, czy mgzip ma szansę nauczyć się także równoległej dekompresji, czy nie bardzo.
      
      W takich sytuacjach zysk jest mnożony przez tysiące osób, które będą miały szybszą instalację systemu, a koszta są niewielkie (dociążenie buildera i pomijalnie mały wzrost objętości plików). W mniejszym stopniu ma to znaczenie przy dużych aktualizacjach systemu (bo zwykle robi się to przez sieć, a rzeczywiście najdłużej trwa zasysanie), a nie każdy aktualizuje system na bieżąco.
      
      Odpowiedz
    2. rjc
      
      15 lutego 2008
      
      Dane w środku deba, który nota bene jest zwyczajnym archiwem 'ar', mogą być skompresowane gzip'em lub bzip2'em.
      
      Odpowiedz
3. michuk
  
  15 lutego 2008
  
  wątpię, czy istnieje zastosowanie (zwłaszcza komercyjne), w którym skrócenie czasu kompresji przełoży się na jakieś znaczące zyski
  
  Miałem jakiś czas temu w projekcie taką sytuację, że trzeba było zautomatyzować przesyłanie plików przez sieć. Polegało to na tym, że plik był tworzony na jednym serwerze, a przetwarzany na drugim (nie było to do obejścia), a czas przetworzenia był kluczowy. Dużo czasu spędziliśmy na optymalizacji, w końcu zrobiliśmy to przez przesyłanie strumienia tar/gzip po ssh i jednoczesne odbieranie i rozpakowywanie go po stronie serwera odbiorcy (strumienie uniksowe, dobra rzecz :P).
  Jako że dziennie przesyłanych było tym sposobem kilkanaście nagranych płyt DVD z danymi, każda optymalizacja była na wagę złota.
  Tak więc tak — są zastosowania "biznesowe" i myślę, że ten nasz przypadek zdecydowanie nie był jedyny. Czas to pieniądz, często dosłownie.
  
  Odpowiedz
Mieszko Kaczmarczyk

15 lutego 2008

""ale przyspiesza rozpakowywanie tylko plików .bz2 stworzonych przez siebie.""

A czy też tylko sam po sobie rozpakuje czy też trzyma standard???

Odpowiedz