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

[Peter Pentchev <roam@xxxxxxxxxxx>]

On Wed, Aug 25, 2004 at 12:27:01PM +0300, George Danchev wrote:
> 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 на компресията.

Повечето от нещата, които казваш, изглеждат май малко по-верни от някои
от тези, които аз изпонаизписах, само че има едно-две неща, които не
схващам съвсем - виж по-долу.  А между другото, оказа се, че през цялото
време съм писал глупости по отношение на една от страните на влиянието
на размера на блока на tar, но за това ще драсна отделен мейл :(

> Очевидно е най-приемливо bzip2 да получи на вход _наготово_ максимален
> размер на блока който може да обработи (за да постигне максимална
> компресия с много малко cpu cycles жертви), а не да получи блокове
> различни от 900,000 bytes (the default) и да реблоква излишно.

Какво точно искаш да кажеш с това 'да получи на вход'?  Ако имаш предвид
да се даде на tar опция -b 1800, така че то да прави write() на парчета
от 900KB и bzip2 да получава по 900KB при всеки read(), аз виждам два
възможни сериозни проблема с това:

1. Не съм сигурен, че write() на 900KB ще бъде atomic; много по-вероятно
   е то или да върне short byte count - да върне стойност, по-малка от
   899981, така че да трябва tar след това да направи втори write() на
   остатъка, или да каже на tar, че всичко е наред, обаче всъщност да
   подаде на bzip2 *няколко* по-малки парчета.  И в двата случая bzip2
   няма да получи 899981 байта наведнъж, ако това е, което си имал
   предвид.

2. Всъщност това е доста подобно на първото - при положение, че tar и
   bzip2 обикновено се използват в pipe (tar -cf - | bzip2 > foo или
   tar -cjf foo.tar.bz2, като при втория вариант tar сам изпълнява bzip2
   и подава входа чрез pipe), то според мен е много вероятно наистина
   една pipe да не може да поеме 899981 байта наведнъж.  Не съм сигурен
   за Linux, но в момента гледам src/sys/kern/sys_pipe.c за FreeBSD
   5.3-BETA1 as of today и ми изглежда, че максималният размер на нещо,
   което може да мине atomically през една pipe, е BIG_PIPE_SIZE, което
   всъщност е 64KB.  При това положение дори и теоретично няма начин tar
   да подаде на bzip2 един цял блок данни от 899981 байта, т.е. няма
   начин bzip2 да направи read() и с *един* read() да прочете 899981
   байта :(

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

Да, знам, че по принцип изобщо не е добра идея на bzip2 да му се дава
малък block size.  Идеята за block size от 100KB беше само за да
илюстрирам единствения случай, в който според мен можеше да има
намаляване на производителността на tar/bzip2.  Според мен също няма
никаква, ама никаква причина (освен ако 8MB памет не са много) изобщо
някога да се използва bzip2 block size, по-малък от 900KB.  Looks like
we're in violent agreement on this one :)  Ако съм те разбрал правилно,
единственото, по което мненията ни малко се различаваха, беше, че ми се
стори, че искаш да кажеш, че най-добрият вариант ще бъде да се укаже на
tar да използва блокове по 900KB, защото така са най-удобни на bzip2 -
само че това просто не е възможно, или по-скоро не е възможно да донесе
исканото повишаване на производителността :(

Поздрави,
Петър

-- 
Peter Pentchev	roam@xxxxxxxxxxx    roam@xxxxxxxx    roam@xxxxxxxxxxx
PGP key:	http://people.FreeBSD.org/~roam/roam.key.asc
Key fingerprint	FDBA FD79 C26F 3C51 C95E  DF9E ED18 B68D 1619 4553
If this sentence didn't exist, somebody would have invented it.

Attachment: pgpKlG21p2IEF.pgp
Description: PGP signature