|
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.