[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 8 Aug 2012 16:08:10 -0700
From: Isaac Dunham <idunham@...abit.com>
To: musl@...ts.openwall.com
Subject: Re: crypt* files in crypt directory
On Wed, 8 Aug 2012 17:48:55 -0400
Rich Felker <dalias@...ifal.cx> wrote:
> > > Maybe you could support -DFAST_CRYPT or the like. It could enable
> > > forced inlining and manual unrolls in crypt_blowfish.c.
..
> Unless there's a really compelling reason to do so, I'd like to avoid
> having multiple alternative versions of the same code in a codebase.
> It makes it so there's more combinations you have to test to be sure
> the code works and doesn't have regressions.
>
> As it stands, the code I posted with the manual unrolling removed
> performs _better_ than the manually unrolled code with gcc 4 on x86_64
> when optimized for speed, and it's 33% smaller when optimized for
> size.
Per your own tests?
I say this because the test previously mentioned shows the
opposite:
> > The impact on x86-64 is less. With Ubuntu 12.04's gcc 4.6.3 on
> > FX-8120 I get 490 c/s for the original code, 450 c/s for your code
> > without inlining/unrolling, and somehow only 430 c/s with
> > -finline-functions -funroll-loops.
that's :
Raw %speed version
490 c/s 100% original
450 c/s 92% rich's version
430 c/s 88% rich's version, unrolled by compiler
Higher is faster.
IE, unrolling is actually slowing your version down more.
GCC 3/x86 is getting 80% with rich's version, optimized.
Also, how much "bloat" does solar designer's proposal (unroll inside
BF_body) add?
Isaac Dunham
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.
