Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
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.