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

[Peter Pentchev <roam@xxxxxxxxxxx>]

On Wed, Aug 25, 2004 at 06:16:54PM +0300, Nikolay Mitev wrote:
> Здравейте.
> 
> 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, вместо да буферира 
> данните в голям блок). 

Мда, честно казано и аз мисля, че за bzip2 не би трябвало да има голямо
значение колко read()'s прави, за да се докопа до един блок от 900KB.
Това, което написах, беше, защото реших, че Георги има пък точно това
предвид, като говори за реблокване, и ми се стори, че няма начин да
се избегне реблокването - въпреки че всъщност не би трябвало да оказва
никакво лошо влияние.

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

-- 
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
I am jealous of the first word in this sentence.

Attachment: pgpwW67JBV31v.pgp
Description: PGP signature