[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
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.
