Follow @Openwall on Twitter for new release announcements and other news
[<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.