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 ============================================================================
