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

[Nikolay Mitev <nikolaymitev@xxxxxxx>]

Здравейте.

Peter Pentchev wrote:

> 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 байта наведнъж, ако това е, което си имал
>   предвид.
>  
Това няма значение. Тук става въпрос за това върху блок от колко байта 
ще бъде извършена компресията.  А на колко части ще пристигнат не е от 
значение, освен за syscall  overhead-a разбира се. Bzip2 спокойно може 
да си алокира голям буфер и да го напълни целия (било то и с няколко 
read-а), и чак _след_ това да го компресира (не съм гледал src, но би 
било дебилно да компресира върнатото от всеки read, вместо да буферира 
данните в голям блок). 

> 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
>   байта :(
>  
Пак същото, виж горния коментар.


<snip>

cheers,
face
============================================================================
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
============================================================================