[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20150506175348.GA6552@openwall.com>
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.
