Linux-Bulgaria.ORG
навигация

 

начало

пощенски списък

архив на групата

семинари ...

документи

как да ...

 

 

Предишно писмо Следващо писмо Предишно по тема Следващо по тема По Дата По тема (thread)

Re: lug-bg: влияние на размера на блока


  • Subject: Re: lug-bg: влияние на размера на блока
  • From: George Danchev <danchev@xxxxxxxxx>
  • Date: Wed, 25 Aug 2004 12:27:01 +0300

On Tuesday 24 August 2004 17:49, Peter Pentchev wrote:
> On Tue, Aug 24, 2004 at 05:26:37PM +0300, Romeo Ninov wrote:
> > Peter Pentchev wrote:
> > >On Tue, Aug 24, 2004 at 03:17:06PM +0300, George Danchev wrote:
> > >>On Tuesday 24 August 2004 13:57, Romeo Ninov wrote:
> > >>>Имам следната ситуация:
> > >>>изшълнявам следната команда tar cf - <files>|bzip2 -9
> > >>>Интересува ме има ли някой идея какво е влиянието на размера на блока,
> > >>>дефиниран от tar :  --block-size=N върху степента и скоростта на
> > >>>компресия  на bzip2
> > >>
> > >>накратко: написано е доста културно в man bzip2...
> > >>четеш от тази секция надолу ...
> > >
> > >Според мен Ромео питаше за block size на tar, не на bzip2 :)
> >
> > Петре, според мен забележката на Георги си е съвсем на място, защото
> > изхода на tar е вход на bzip2 и оказва влияние, особено при размер на
> > блока около 900 килобайта (какъвто е на bzip2-а при -9)
>
> Ммм.. то че оказва влияние, оказва, само че в съвсем друга посока :)

Само, че си объркал посоката ? Аз никъде не съм посочил дали размера на блока 
ще се сетва в едната или другата програма (то е очевадно), посочих bzip2 
performance issues щото това касае ratio & speed на компресията. Очевидно е 
най-приемливо bzip2 да получи на вход _наготово_ максимален размер на блока 
който може да обработи (за да постигне максимална компресия с много малко cpu 
cycles жертви), а не да получи блокове различни от 900,000 bytes (the 
default) и да реблоква излишно.

> Поне както аз виждам нещата, единственият случай, в който размерът на
> блоковете на bzip2 ще има значение, ще бъде този:
>
> 1. имаш множество малки файлчета;
> 2. слагаш голям размер на блок за tar, така че изходът на tar има
>    доста повече нули, отколкото истински данни, *и*
> 3. слагаш *малък* размер на блок за bzip2 

при малък размер ще reblock-ваш което е излишен performance impact.
нека си постъпват на входа големи (900к) за да не реблокваш и да компресваш 
най-изгодно.

> (или просто даваш на tar 
>    размер около 900KB), така че във всеки блок на bzip2 има много повече
>    нули, отколкото истински данни.

е -9 (900,000 bytes) не е ли максималния block size който може да обработи 
bzip2. Значи се връщаме на "големи" блокове все пак.. и ако ги получава на 
входа направо такива ще излезе най-евтино.

> Резултат ще бъде, че bzip2 няма да може да използва данните от предишния
> файл за компресия на следващия, защото за всеки блок използва алгоритъма
> си за компресия на repetitive data и защото просто *не вижда* данните от
> предишния файл: те са в предишния bzip2 блок :)

Оппа, bzip2 гледа и сортва (repetitive/non-repetitive) blocks, така, че вижда 
всички блокове и немаа се плашиш за лихвата;-) Само не ми стана ясно дали 
върху всеки от блоковете поотделно прави BWT [1] (block-sorting) или за 
всички блокове като цяло прилага еднократно BWT... но и това може да се 
изясни от blocksoft.c. Така, че не е от значение дали данните от кой файл в 
кой блок са, те пак ще бъдат ротейтнати и сортнати по BWT... правят се и 
някой други номера с други алгоритми, не е само BWT... пък и CRC сума има на 
блока за консистентност.

> С изключение на този случай, размерът на блока на bzip2 би трябвало да
> има значение само дотолкова, доколкото колкото е по-голям, толкова
> по-добра компресия ще получиш - затова и стойността му по подразбиране е
> максимална (900KB).  Поне така ми се струва :)

извода е, че е най-изгодно е да не се променя размера който е по-подразбиране 
в bzip2, а да се получават такива блокове на входа на готово... е последния 
блок ако е къс ще бъде допълнен, което може да се пренебрегне като импакт.

[1] http://www.fact-index.com/b/bu/burrows_wheeler_transform.html
-- 
pub 4096R/0E4BD0AB  2003-03-18  <keyserver.bu.edu ; pgp.mit.edu>
fingerprint 1AE7 7C66 0A26 5BFF DF22 5D55 1C57 0C89 0E4B D0AB 
============================================================================
A mail-list of Linux Users Group - Bulgaria (bulgarian linuxers).
http://www.linux-bulgaria.org - Hosted by Internet Group Ltd. - Stara Zagora
To unsubscribe: http://www.linux-bulgaria.org/public/mail_list.html
============================================================================



 

наши приятели

 

линукс за българи
http://linux-bg.org

FSA-BG
http://fsa-bg.org

OpenFest
http://openfest.org

FreeBSD BG
http://bg-freebsd.org

KDE-BG
http://kde.fsa-bg.org/

Gnome-BG
http://gnome.cult.bg/

проект OpenFMI
http://openfmi.net

NetField Forum
http://netField.ludost.net/forum/

 

 

Linux-Bulgaria.ORG

Mailing list messages are © Copyright their authors.