[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20150916224853.GA14368@openwall.com>
Date: Thu, 17 Sep 2015 01:48:53 +0300
From: Solar Designer <solar@...nwall.com>
To: john-dev@...ts.openwall.com
Subject: Re: multi-threaded hash table initialization
On Thu, Sep 17, 2015 at 01:18:41AM +0300, Solar Designer wrote:
> I think we can commit it and give it some more testing. There might be
> regressions for other cases, especially multi-salt with small per-salt
> hash tables - maybe we need to add a check for that (would need to come
> up with a hash table size threshold).
For multi-salt with large enough per-salt hash tables, an optimization
would be to spawn the 3 threads in ldr_init_hash() and have it call
ldr_init_hash_for_salt() separately from each thread, passing the thread
id in there. Then instead of the 3 OpenMP sections,
ldr_init_hash_for_salt() would check the thread id passed into it and
run one of the corresponding 3 code blocks. This would eliminate the
unnecessary synchronization barriers between the salts. There would be
no drawbacks from this optimization for other cases as well, so if we
choose to implement it we'd only need this one version of the code.
Oh, I just realized the same may be achieved by adding the nowait clause
to the existing "#pragma omp parallel sections" in
ldr_init_hash_for_salt(), and adding an explicit barrier at the end of
ldr_init_hash(). Maybe we should try that with some multi-salt file
with many hashes per salt.
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.
