Re: [RFC] split floppy support off biosdisk

[Javier Martín]

El mar, 17-06-2008 a las 23:49 -0400, Pavel Roskin escribió:
> On Wed, 2008-06-18 at 05:14 +0200, Javier Martín wrote:
> 
> > ORIGINAL FILE: /boot/grub/core.img (28449 bytes in Ubuntu Hardy default)
> 
> That's an already compressed file!  Please see my posts in the thread.
> We should be testing compression on the data we are actually
> compressing.
Yeah, I noticed it _after_ posting and sent another message to the
effect. I repeated the tests, now with an uncompressed image. For the
"scientific method" guys wanting to repeat or extend the test, this is
how the it was performed:

/boot/grub$ cat kernel.img pc.mod fshelp.mod ext2.mod > ~/core.img
/boot/grub$ cd
~$ stat -c %s core.img
40412   # Size of the uncompressed file (for later)
~$ for n in {1..9}; do
        lzop core.img -c -$n > ./core.$n.lzo
        gzip core.img -c -$n > ./core.$n.gz
        bzip2 core.img -c -k -$n > ./core.$n.bz2
        lzma core.img -c -k -$n > ./core.$n.lzma
done 
~$ for comp in lzo gz bz2 lzma; do
        echo $comp
        for n in {1..9}; do
                echo $(stat -c %s ./core.$n.$comp)-$(dc -e "2 k 100 $(stat -c %
s ./core.$n.$comp) 404.12 / - p")
        done
done

For me, the results are:

CL     LZO-%sav    GZIP-%sav   BZIP2-%sav    LZMA-%sav
 1   29391-27.3   24171-40.2   22979-43.2   21569-46.7
 2   29279-27.6   23913-40.9        x       21567-46.7
 3  *     x       23785-41.2        x       20922-48.3
 4        x       23350-42.3        x            x
 5        x       23148-42.8        x       20924-48.3
 6        x      *23074-43.0        x            x
 7   25250-37.6   23071-43.0        x      *     x
 8   25163-37.8   23045-43.0        x       20929-48.3
 9   25162-37.8   23035-43.0  *     x            x
Where:
* indicates the default compression level
x indicates "same as above"
The original file size was 40412 bytes

I hope the results are a bit more useful this time. The "uncompressed
chunk" of nearly 1KiB was not taken into account, i.e. the whole file
was compressed by every algorithm. My conclusions are:
* LZO is pretty bad unless we set the maximum compression level, which
is not a problem because required memory and CPU is still nearly zero.
Seemingly, grub-mkimage already compresses with high CLs because the
core.img it generated with the same parameters than my cat'ed test image
was 25928 bytes long, with the uncompressed part and the decompressor.
* GZip is okay in its default compression level of -6, but, as LZO, we
don't lose nearly anything in terms of CPU and memory by pushing it to
-9. The particular advantage of this algorithm is that is already
implemented for this same purpose in the Linux kernel, so may be we
could use copy-paste to some point and relieve us some work. We'd save
up to 2 KiB in my test image, assuming similar decompressor size.
* BZip2 is also fine - its results are immutable throughout the CLs, I
suppose because the whole file fits in its -1 compression dictionary of
100 KiB. I don't think we'd benefit a lot from this particular algorithm
with files this small, and thus I prefer GZip over it.
* LZMA is the king of compression, and so we gain more bytes for code,
but at the cost of an implementation of unknown size - the C version of
the decompressor in the coreboot project seemed to be a bit big, but
maybe our local assembly gurus could tune it down. We'd save up to 4 KiB
in my test image, assuming similar decompressor size.

I hope I did not make any embarrassing mistakes this time :-)

signature.asc
Description: Esta parte del mensaje está firmada digitalmente