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

[Peter Pentchev <roam@xxxxxxxxxxx>]

On Wed, Aug 25, 2004 at 02:53:42PM +0300, George Danchev wrote:
> On Wednesday 25 August 2004 13:17, Peter Pentchev wrote:
> --cut--
> > Какво точно искаш да кажеш с това 'да получи на вход'?  Ако имаш предвид
> > да се даде на tar опция -b 1800, така че то да прави write() на парчета
> > от 900KB и bzip2 да получава по 900KB при всеки read(), аз виждам два
> > възможни сериозни проблема с това:
> 
> Мда, точно така, не виждам нищо лошо в:
> tar cf - dir -b 1800 | bzip2 > dir.tar.bz2

Значи да попитам пак: смяташ, че ако размерът на изходния блок на tar е
равен на размера на входния блок на bzip2, това ще доведе до повишаване
на производителността, така ли?  Един малко тъп въпрос: защо?  Т.е. как?
Т.е. какво точно смяташ, че ще се подобри?

Единственото, което на мен ми се струва възможно да се подобри, е това
bzip2 да си получава входа с по-малко работа, т.е. с по-малко syscalls,
т.е. да получава по 900KB (или по-точно по 899981 байта) при всяко
извикване на read() - а това е *точно* това, което смятам, че няма начин
да стане :)  Ако имаш някаква друга идея за това как точно ще се подобри
работата на bzip2, ако на tar му зададеш -b 1800, казвай!

А на всичкото отгоре тук има и допълнителен момент: числото 899981 съм
го взел от това, което показва bzip2 -vv9 largefile.  Т.е. блоковете на
bzip2 всъщност *не са* по 900KB, а са по 899981 байта, и на практика
няма начин да убедиш tar да прави точно толкова големи блокове, колкото
bzip2 иска, така че цялата тази история е още малко безсмислена май...

> макар, че чак сега се замислям над това и до сега не съм го ползвал.
> Но сега го изтествах няколко/доста пъти и с дифф проверих наистина ли 
> оригинала се запазва след горното архивиране/компресиране и 
> декомпресиране/деархивиране. Ми всичко е ОК.

Нее, като говоря за сериозни проблеми нямам предвид загуба на данни :)
Май пак не се изразих както трябва :)  Имам предвид причини това да не
доведе до повишаване на производителността.

> Нямам време да тествам с time и да гледам compress ratio-то на горното с и без 
> разни стойности на -b, но -b 1800 приляга според мен идеално на -9 на 
> bzip2 ;-)

И пак питам - как и защо? :)

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

Така де, така - и точно затова ядрото и от двата края на пайпа не
поддържа блокове по 899981, следователно bzip2 няма начин да прочете
наведнъж 899981 байта - и с какво ще се подобри работата му тогава?
Особено при положение, че 1800 * 512 != 899981 :)

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

-- 
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
What would this sentence be like if pi were 3?

Attachment: pgpR6Mth1l9OY.pgp
Description: PGP signature