john-dev - RE: Got all dyna formats (except $1$ and $apr1$) working with OMP

Follow @Openwall on Twitter for new release announcements and other news

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <017a01ce3d36$9af18190$d0d484b0$@net>
Date: Fri, 19 Apr 2013 14:46:37 -0500
From: "jfoug" <jfoug@....net>
To: <john-dev@...ts.openwall.com>
Subject: RE: Got all dyna formats (except $1$ and $apr1$) working with OMP

From: magnum Sent: Friday, April 19, 2013 13:33
>
>Sometimes the optimizers do really astonishing things, sometimes they,
well, don't.

What happened here, was a standard memory access to a static data element
was changed to an inline function call.  If we were building with OMP, then
within that inline function call there was an external call, and not simply
a memory read.

Here is the code as I originally did it (in the string copy sections)

.....
   if (md5_unicode_convert) {
 .....
   } else {
   }

This changed to:

.....
   if (md5_unicode_convert_get()) {
 .....
   } else {
   }

with the md5_unicode_convert_get function being:

static inline int md5_unicode_convert_get() {
#ifdef _OPENMP
	return md5_unicode_convert[omp_get_thread_num()];
#else
	return md5_unicode_convert[0];
#endif
}

So the original code went from:
   if(somevar) ...
to
   if(somevar[omp_get_thread_num()]) ....

if in OMP mode.  That is a HUGE change if done a couple million times per
second, and was not an obvious side effect at first.

So the parent function parameters were changed, so that the threadid is
passed in, and the if() was changed to:

if(md5_unicode_convert_get(tid))

and the inline function (which actually now could be eliminated) is:

static inline int md5_unicode_convert_get(int tid) {
	return md5_unicode_convert[tid];
}

so now our code ends up being changed from this:
   if(somevar) ...
to this:
   if(somevar[tid]) ...

That is a huge improvement.   However, the downside is we now have to pass
around the tid as a param.

It 'may' be that I can go from 3 params, to 1, and simply pass a pointer to
an object owned by the thread. That object would contain the 3 params
(starting candidate, ending candidate, and thread id).  However now every
access would have a pointer dereference to get to those data items.  I am
not sure if that would be a gain or loss.  But it may be a 'good' gain, as I
could possibly eliminate some mmx_coef 'math' done at many steps. Do that
work 1 time, and then simply access the variables, vs having to access them,
modify them, and then proceed.  I will look into this.   Weekend is coming
up, and I think I will have to time experiment some.

I will be getting the patch to the 'current' 3 param changes in very soon.
I am running some final testing on it now.

Jim.

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.