From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1K8w1l-0001Rk-Mn for mharc-grub-devel@gnu.org; Wed, 18 Jun 2008 07:40:37 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1K8w1k-0001RE-5x for grub-devel@gnu.org; Wed, 18 Jun 2008 07:40:36 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1K8w1h-0001QV-8S for grub-devel@gnu.org; Wed, 18 Jun 2008 07:40:35 -0400 Received: from [199.232.76.173] (port=37175 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1K8w1h-0001QS-1D for grub-devel@gnu.org; Wed, 18 Jun 2008 07:40:33 -0400 Received: from wx-out-0506.google.com ([66.249.82.231]:2042) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1K8w1g-00050k-Cm for grub-devel@gnu.org; Wed, 18 Jun 2008 07:40:32 -0400 Received: by wx-out-0506.google.com with SMTP id h28so65565wxd.24 for ; Wed, 18 Jun 2008 04:40:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:from:to:in-reply-to :references:content-type:date:message-id:mime-version:x-mailer; bh=YPuEd70asBvw/Z+RpHbZXJCIwJQNZUgUyLdUqinRxnw=; b=VCKWcfZRFAmkcpLwntarVfCKtEQgqG1MgLOoWdzXUmoV8V0JJnGpYhsR/4ovFjZjz0 o06j4LkvZzwJBgfIJlyW2YoPMPdksIb+rLMp/Kw2YOJAyqwPrl3liNK2IFoVsEnZ/z6E 3hPPA19hQ5P8aHJ076vKS2/Ju9I2G5RMhuTUI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:from:to:in-reply-to:references:content-type:date:message-id :mime-version:x-mailer; b=PMb0tDOYqcGBrm3AzgFmN2lGMB8ojEZnfwaUlKsyuMc5ipCnqJX3yx6EIzCyjdQyd4 DvSUvSyiQnghOa0yJd2QVHSKzFgBLAAKheJyLsZ1gHrxbxYFl6qUxFquaC2t/WgBvIeT ZS3TEEn9Ckd/vLLiQG4KjMt/cY/smkQaVnTSQ= Received: by 10.70.40.1 with SMTP id n1mr624934wxn.5.1213789231436; Wed, 18 Jun 2008 04:40:31 -0700 (PDT) Received: from ?192.168.1.100? ( [213.37.137.93]) by mx.google.com with ESMTPS id i18sm11761636wxd.16.2008.06.18.04.40.29 (version=SSLv3 cipher=RC4-MD5); Wed, 18 Jun 2008 04:40:30 -0700 (PDT) From: Javier =?ISO-8859-1?Q?Mart=EDn?= To: The development of GRUB 2 In-Reply-To: <1213760967.2940.8.camel@rd> References: <20080615174819.GA3506@thorin> <1213618146.6330.6.camel@localhost> <20080616213116.GC6108@thorin> <1213670869.6330.12.camel@localhost> <1213713543.6330.24.camel@localhost> <1213723385.6330.35.camel@localhost> <1213758847.6330.59.camel@localhost> <1213760967.2940.8.camel@rd> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-RxCBogIlFxfz9egncAZQ" Date: Wed, 18 Jun 2008 13:40:26 +0200 Message-Id: <1213789226.7112.29.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.22.2 X-detected-kernel: by monty-python.gnu.org: Linux 2.6 (newer, 2) Subject: Re: [RFC] split floppy support off biosdisk X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: The development of GRUB 2 List-Id: The development of GRUB 2 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jun 2008 11:40:36 -0000 --=-RxCBogIlFxfz9egncAZQ Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable El mar, 17-06-2008 a las 23:49 -0400, Pavel Roskin escribi=C3=B3: > On Wed, 2008-06-18 at 05:14 +0200, Javier Mart=C3=ADn wrote: >=20 > > ORIGINAL FILE: /boot/grub/core.img (28449 bytes in Ubuntu Hardy default= ) >=20 > 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=20 ~$ 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 =EF=BB=BF BZIP2-%sav LZMA-%sav 1 29391-27.3 =EF=BB=BF24171-40.2 =EF=BB=BF 22979-43.2 =EF=BB=BF2156= 9-46.7 2 29279-27.6 =EF=BB=BF23913-40.9 x =EF=BB=BF21567-46.7 3 * x =EF=BB=BF=EF=BB=BF23785-41.2 x =EF=BB=BF2092= 2-48.3 4 x =EF=BB=BF23350-42.3 x x 5 x =EF=BB=BF23148-42.8 x =EF=BB=BF20924-48.3 6 x *=EF=BB=BF23074-43.0 x x 7 =EF=BB=BF25250-37.6 =EF=BB=BF23071-43.0 x *=EF=BB=BF = x 8 =EF=BB=BF25163-37.8 =EF=BB=BF23045-43.0 x =EF=BB=BF2092= 9-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 :-)=20 --=-RxCBogIlFxfz9egncAZQ Content-Type: application/pgp-signature; name=signature.asc Content-Description: Esta parte del mensaje =?ISO-8859-1?Q?est=E1?= firmada digitalmente -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iQIVAwUASFj0KqSl+Fbdeo72AQIXNw/7BPSVoMpUj3x+J/IZfwKJgZvmcslFcGr3 uWNJKroh/AA57Sqrn5gtRo1NEyuAZ7lYwc8r7ykEbyLGbsemaPwZWM9r2ETRfdwl yI/0A1FD8xQWsvZmKsGeGR3Jttmi7mpSU9UnSW62F05596V6ia6GGyCAvH6I5KqU or2eMnB4eKBr9PUVkcMa02sQd0VdwV3Ez91FyOiZ6NCdk83SlYvzDJHuJxbomDf1 VynsRAcKPnq6xl7tyNU60Q5dxk62iShZs8SJH3kBIKJZdVNaDLZYyTqwhB5KFTMl m/2zuxao1XQEbG7/SEQgXl6HZbHxhQubamwT4nXHovcyKFjeHLZpqEWdzlzLtKjm 93ZwJVVHbuVIZcfLdW6A17IM8md6zevliYue1rIRSL7DMSDcTBAHjtNYOmCs7auo 1wjv29Q00Hfb1YOM+j+1azdnFZuAAtCIz8tVJvA6eXJkZLG85kOQE0ZtgJidpy7Q /tae9yEBqNYIOn/QSmRY4nCvYg3uu1dkLFOyWD0OyVos43ObafJn4vImDA3eQ/m1 Kd+pm3/wLpmNYynkQUHj2W0SRh6TcvXaqXlcKikWlaFfsvDPEUA73SezaJBpR+i5 pfFlQ764WemLZf5fYJcpCqhwUisARHEfdCqcjkXpTszRto+eF3eSPF4KBU5XiLZe N7CinOQ3si4= =h1oh -----END PGP SIGNATURE----- --=-RxCBogIlFxfz9egncAZQ--