[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: ramblings about old hardware, gzip, bz2, and pentium opts

On Mon, Nov 29, 1999 at 04:41:22PM -0700, Jason Gunthorpe wrote:
> Remember that povray is a FPU bound program and IIRC there are no
> significant FPU optimization techniques (or gcc doesn't know about them) 
> between the various chips.
> A better test is to use gzip on a large file from cache or some other
> integer program.

   povray is surprisingly more integer-bound than FPU bound in most cases. 
It traverses a lot of lists, functions, and conditional clauses before it
does a floating point calculation.  Under IRIX the performance doubles with
IPA (interprocedural analysis) flags enabled, but gcc doesn't really have
these (it can inline functions, but only at compile time, not link time I
believe).  Povray is probably a good general test though as it has complex
compiler-like memory access patterns coupled to FPU intensive code,
exercising a whole range of operations.  If the FPU part is identical across
arch-flags then the integer differences will show through instead.
   For package management speed gzip would indeed be a better benchmark.

   On the bzip/gzip issue I think people should be aware that Andrew
Tridgell has a plan to make gzipped data rsyncable, using relatively small
gzip blocks divided by a rolling checksum (rather than a fixed blocklength). 
bzip with it's large blocks won't benefit from this.  This would perhaps
allow foo_1.1_i386.deb to become foo_1.2_i386.deb for 20% of the bandwidth
downloading a new foo_1.2 would cost.  Packages.gz and source archives would
definitely win big between updates like this, so going to bzip2 may not be a
long term plan.  All packages would need to be recompressed to get the
rolling blocks though.
   On implementing this capability: 

gzip would need to do the rolling blocks (not yet done).  package build
tools may need to pass gzip an option to enable it.

Archives would need to cp foo_1.1.deb to foo_1.2.deb before the rsync run
as rsync won't search for common blocks between different files.

dselect/apt could call dpkg-repack to produce a template .deb before
using an rsync archive.

Reply to: