[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 16 Sep 2015 21:11:53 +0300
From: Solar Designer <solar@...nwall.com>
To: john-dev@...ts.openwall.com
Subject: fast hash processing bottlenecks (was: ldr_split_line() performance regression)
On Wed, Sep 16, 2015 at 07:15:36AM +0300, Solar Designer wrote:
> With this patch, it improved to:
>
> real 0m45.481s
> user 2m57.928s
> sys 0m18.315s
>
> which is roughly 24 seconds loading and 21.5 seconds cracking.
Curiously, for only 1 million hashes loaded (shuf|head from the 29M),
it's now 1.5 seconds loading and 20 seconds cracking. So it looks like
there's relatively little left to optimize in terms of the lookups
during cracking, and more in the loader and in wordlist mode and rules
engine.
For 1k hashes, it's 16 seconds.
For 1 hash, it's 15 seconds. Even for 1 hash, the c/s rate is only 1/3
of what we see on --test benchmarks for raw-md5 (~7M out of ~21M per
core on this 2x E5420). So 2/3 is wordlist mode and rules and lookups
overhead (but for only 1 hash it's clearly mostly not lookups).
Once we reduce the wordlist mode and rules overhead, I suppose the
lookups will become a little bit more important to optimize again.
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.
