[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sun, 8 Jul 2012 00:13:54 +0200
From: Frank Dittrich <frank_dittrich@...mail.com>
To: john-dev@...ts.openwall.com
Subject: Re: Between 1.7.9-jumbo-3 and 1.7.9-jumbo-4 performance
of --format=bf dropped by more than 20%
On 07/07/2012 12:53 AM, Solar Designer wrote:
> On Sat, Jul 07, 2012 at 12:04:15AM +0200, Frank Dittrich wrote:
>> ... and stayed at this level.
>
> This is bad news, but dealing with it might not be worth the effort and
> complexity.
I agree.
> Changing BF_X2 from compile-time to runtime (and detecting Atom then)
> would be an invasive change that would significantly add to source code
> complexity.
>
> We could revert to BF_X2 = 0, but that would hurt most uses of 32-bit
> builds, most of which I guess are on non-Atom CPUs.
>
> As a workaround, -x86-any build should regain the old speed for you.
I tested generic, which brought back the old bf speed.
May be we could point out in doc/INSTALL, that we tried to find optimal
settings for the build targets listed, but that for a few exceptions a
generic build can be faster for a particular benchmark than the "most
common" build target for an architecture.
For the jumbo build, we could even point out that trying alternative
compilers like clang vs. gcc or different gcc versions can make a
siginificant difference for those (new) formats which have not been that
much optimized than the core formats.
Frank
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.
