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.