Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20150918155215.GA24888@openwall.com>
Date: Fri, 18 Sep 2015 18:52:15 +0300
From: Solar Designer <solar@...nwall.com>
To: john-dev@...ts.openwall.com
Subject: Re: bitmap & hash table prefetching

On Fri, Sep 18, 2015 at 05:29:01PM +0200, Frank Dittrich wrote:
> On 09/18/2015 04:50 PM, Solar Designer wrote:
> > The attached patch does that, and it assumes that "binary" itself is
> > allocated right after the tiny struct, so doesn't need to be prefetched
> > separately.  This should be suitable for commit now.
> > 
> > The 29M testcase:
> > 
> > real    0m40.821s
> > user    2m55.786s
> > sys     0m14.104s
> 
> I think as long as we have unresolved new bugs that prevent reliably
> cracking hashes, further performance optimization doesn't make that much
> sense.

I agree, although it does to me: I am checking that my tree is producing
the same results as before for the 29M testcase.  As another test I run,
it also cracks some salted hashes fine for me.

> See https://github.com/magnumripper/JohnTheRipper/issues/1769

Ouch.  I thought it was obvious after your john-dev postings that this
commit that magnum made on my behalf:

commit 4c541b32c3a02a1fc4981879359307d273c9b9ca
Author: Solar <solar@...nwall.com>
Date:   Thu Sep 17 12:13:41 2015 +0200

    john-huge-loader-mt.diff, splitting initialization of bitmap
    and hash table into 3 threads.

is problematic for non-OpenMP.

There might or might not be other recent bugs.

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.