[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20120808180319.4c62b21a@newbook>
Date: Wed, 8 Aug 2012 18:03:19 -0700
From: Isaac Dunham <idunham@...abit.com>
To: musl@...ts.openwall.com
Subject: Re: crypt* files in crypt directory
On Thu, 09 Aug 2012 01:24:18 +0200
John Spencer <maillist-musl@...fooze.de> wrote:
> On 08/09/2012 01:08 AM, Isaac Dunham wrote:
> >
> > Also, how much "bloat" does solar designer's proposal (unroll inside
> > BF_body) add?
> On 08/08/2012 07:28 AM, Rich Felker wrote:
>
> The size difference between the versions is roughly 50% (7k vs 11.5k
> with -Os and roughly 9k vs 13.5k with -O3).
That's not for Solar Designer's proposal, it's for Luka's original
patch.
The proposal should be somewhere in between; I have a modified one
that's running ~1.9k more as .o (which I have _not_ made pretty;
it's just for a test!)
But just for comparison, I did a check:
$ size src/misc/crypt_blowfish*o
text data bss dec hex filename
17089 8 0 17097 42c9 src/misc/crypt_blowfish.lo
8738 0 0 8738 2222 src/misc/crypt_blowfish.o
13840 12 0 13852 361c src/misc/crypt_blowfish_old.lo
11430 4 0 11434 2caa src/misc/crypt_blowfish_old.o
17617 8 0 17625 44d9 src/misc/crypt_blowfish_rich.lo
6845 0 0 6845 1abd src/misc/crypt_blowfish_rich.o
All compiled with same flags, using GCC 4.1 on Lucid.
(-Os = .o; -O3 -fPIC = .lo).
> +1 for the size (and clean code) vs speed tradeoff
> crypt is a function that very rarely gets called. better keep it
> non-bloated.
It's interesting that in the shared version (the only case where
crypt() size matters to apps not using it), size seems to be
inverted, with the old manually unrolled version weighing about 4k less.
Isaac Dunham
View attachment "crypt_blowfish.c" of type "text/x-c++src" (30868 bytes)
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
