[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20120121174125.GA13591@openwall.com>
Date: Sat, 21 Jan 2012 21:41:25 +0400
From: Solar Designer <solar@...nwall.com>
To: john-dev@...ts.openwall.com
Subject: eliminating barrier between crypt_all() and hash comparison/lookups (was: bitmaps)
On Mon, Jan 16, 2012 at 06:25:26PM +0400, Solar Designer wrote:
> Some further OpenMP speedup may be possible through eliminating the
> implicit barrier between crypt_all() and the bitmap lookups loop, but
> this is tricky to implement while preserving the generic program
> structure (not specific to a hash type). Well, maybe crypt_all() could
> use nowait and atomic writes to some flags (as well as write barriers),
> and the lookups loop or rather get_hash*() could spin when it sees a
> flag that is not yet set (after a read barrier, although this should not
> matter on x86).
I looked into this possibility. No, it won't work without changing the
program structure significantly because nowait may only be used within a
parallel region, which has to be closed (and thus an implicit barrier
introduced) before the end of the function (crypt_all() in this case).
What we could do is move (or duplicate) some logic from cracker.c,
cmp_*() and get_hash_*() into crypt_all(). The new crypt_all() would
then need to accept e.g. a pointer to struct db_salt, so it would check
if there are possibly any guesses or not before returning control to
cracker.c (which would then identify the specific guessed passwords with
a loop much like it does now - but only if crypt_all() returned that
there might be any). Unfortunately, this mixes up different layers of
the program. While it is no surprise that mixing them should improve
performance at fast hashes, it is bad for code readability and further
maintenance. Also, if implemented the obvious way, we may even get
circular #include's between formats.h and loader.h. Merging these into
one file would probably go against source code readability even further.
So I haven't decided what to do on this yet.
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.
