Date: Wed, 16 Sep 2015 01:20:14 +0300 From: Solar Designer <solar@...nwall.com> To: john-dev@...ts.openwall.com Subject: Re: Judy array On Tue, Sep 15, 2015 at 11:29:10PM +0200, magnum wrote: > On 2015-09-15 21:28, Solar Designer wrote: > >On Tue, Sep 15, 2015 at 09:53:41PM +0300, Solar Designer wrote: > >>We should be able to avoid the ldr_remove_marked() delay by having it > >>skip processing when nothing had been marked for removal. (I am testing > >>with an initially empty john.pot.) > > > >Implemented in the attached patch. It is possible to do better, such as > >with per-salt flags. > > > >Not much change overall, but anyway: > > > >real 1m1.413s > >user 4m48.603s > >sys 0m21.961s > > So should I commit it? Yes, please. Meanwhile, I also tried reducing PASSWORD_HASH_SHR from 2 to 1: real 0m58.804s user 4m26.433s sys 0m18.934s and to 0: real 0m57.022s user 4m15.630s sys 0m16.348s With 0, memory usage by each process at start of cracking is higher by 768 MB (as compared to 2, growing from a little over 2 GB to about 3 GB), but their total RAM usage by end of the 1-minute run is lower than it was with 2 (around 7.5 GB instead of around 8.5 GB). I actually expected this effect: with a larger hash table, when a password gets cracked, there's less need for writes to pages holding "struct db_password" and other things referenced from there. And overall even at 768 MB the hash table remains smaller than those other allocations combined. I am not sure if we should bump up the default. Perhaps on 64-bit only? Or maybe we need to introduce a larger bitmap size first or instead (and then keep SHR=2 or use even larger than 2 relative to that), or maybe Fred will contribute something even better soon. Adjusting the default is easy, so we may as well just do it for 64-bit for now, then revise. 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.