[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20150701160505.GA12490@openwall.com>
Date: Wed, 1 Jul 2015 19:05:05 +0300
From: Solar Designer <solar@...nwall.com>
To: john-dev@...ts.openwall.com
Subject: Re: JtR on Power
On Wed, Jul 01, 2015 at 04:52:29PM +0200, Frank Dittrich wrote:
> On 07/01/2015 04:39 PM, Solar Designer wrote:
> > Great! Please note that POWER can be 32- or 64-bit, big- or
> > little-endian. All four combinations are possible, depending on the
> > operating system. So we need actual detection of word size and
> > endianness, like we had in "make generic" before. Unfortunately, magnum
> > dropped that when adding autoconf support, but I think we need to
> > reintroduce it.
>
> make generic wasn't dropped.
I meant that equivalent functionality wasn't reimplemented in autoconf,
which is the official way to build jumbo now.
> There's still that Makefile.legacy, and from time to time, some effort
> goes into testing
>
> make -s -f Makefile.legacy clean generic
> make -s -f Makefile.legacy clean linux-x86-64-native
> etc.
Great!
> Currently, we have a state with just a few known issues:
>
> 1.
> crypt(3) fails for linux-x86-64-native (fails to build or segfaults,
> depending on OpenMP, du to messed up ifdefs for crypt / crypt_r, see
> https://github.com/magnumripper/JohnTheRipper/issues/1471
This needs to be fixed.
> BTW:
> I'd like to have a best.sh change for generic, trying even higher values
> for BF_X2 as long as the next value results in better performance than
> the previous one.
The best.sh benchmark is single-threaded. Better performance for
1 thread doesn't imply better performance for 2 threads/core, and for
the bcrypt code this is in fact known to sometimes not be the case.
> (On Haswell that results in a much better c/s rate for generic than for
> the autoconf build.)
You mean on your HT-less Haswell. ;-)
This is one of the reasons why I tried to work on assembly code for
bcrypt, hoping that while at it I'd happen to arrive at a code version
that would be optimal for both 1 thread/core and 2 threads/core at once.
And I almost did, but it's still slightly slower than our C code on some
CPUs in some builds.
> But that is probaly best done in core (may be after renaming BF_X2).
Yes.
Alexander
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.
