Date: Wed, 6 May 2015 20:53:48 +0300 From: Solar Designer <solar@...nwall.com> To: john-dev@...ts.openwall.com Subject: Re: [GSoC] JtR SIMD support enhancements Lei, On Wed, May 06, 2015 at 01:09:22PM +0300, Solar Designer wrote: > On Wed, May 06, 2015 at 10:56:00AM +0800, Lei Zhang wrote: > > I'm not sure where OMP_SCALE is defined for phpass. I guess it's in dynamic_types.h, and that's the result after tuning it: > > > > OMP_SCALE Result > > ----------------------------------- > > 1 18249 c/s real, 75.9 c/s virtual > > 4 18917 c/s real, 79.1 c/s virtual > > 16 18629 c/s real, 77.5 c/s virtual > > 64 18541 c/s real, 77.8 c/s virtual > > 256 18541 c/s real, 77.7 c/s virtual > > > > It appears tuning OMP_SCALE makes not much difference here. BTW, setting OMP_SCALE to 2048 or higher would cause the failure of memory allocation. From this experiment, I'm uncertain about if OMP_SCALE has a significant impact on synchronization overhead. > > That's weird. Either that OMP_SCALE in dynamic_types.h isn't affecting > phpass as we want it to, or the bottleneck is different. A way to see if OMP_SCALE takes effect is to run an actual cracking session on phpass hash(es) and look at the log file line produced here: if (chunk > 1) log_event("- Candidate passwords %s be buffered and " "tried in chunks of %d", min_chunk > 1 ? "will" : "may", chunk); The number of chunks reported here should be increasing as you increase OMP_SCALE. Please perform this test. Thanks, 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.