[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 2 Feb 2012 15:21:32 +0000
From: Alex Sicamiotis <alekshs@...mail.com>
To: <john-users@...ts.openwall.com>
Subject: RE: DES with OpenMP
>
> Thank you for running these tests and providing the results. What about
> the effect this has on LM hash speed?
>
Hmm.. did not know that LM was affected by DES parameters but apparently they are :D
Again, moving down from 32 to lower values brought significant gains - especially in 2 threads. LM seems to be "settled" at a value of 8. While for plain DES the ideal value is 1, still with a value of 8 there's not much performance impact for it while the LM benefits enormously. 8 seems to be the perfect balance (for my hardware and across both GCC and ICC) and you might consider it for the next john release after testing with other hardware as well.
I've done
* a run with GCC 4.6.2 with values of 1-4-8-16-32 at plain DES (1 & 2 threads)
* a run with GCC 4.6.2 with values of 1-4-8-16-32 at LM (1 & 2 threads)
* a run with ICC 12.1 with values of 1-4-8-16-32 at LM (1 & threads)
Results are here: http://imageshack.us/f/710/resultsarein1.png/
I've highlighted the gains below from the faster non-32 variant to the default 32 value. 32 seems to be the tipping point of losing large chunks of performance.
> BTW, you could similarly experiment with MD5_std_cpt (MD5_std.h) and
> BF_cpt (BF_std.h). These should make a lot less of a difference (and
> for their respective hash types only), though.
>
> Alexander
I may try it in the days ahead when I have access to icc again (or may do it with gcc 4.6.2 instead - the results seems to be quite similar anyway).
In the meanwhile my curiosity has peaked as to why the openMP version is producing ~250 to 300k c/s over the standard non-omp client (4750k c/s vs 4450-4500k c/s). Several things being equal (no-asm for both, icc for both, non-hardware optimizations for both, a value of 1 for des_bs_cpt for both, definite use of just 1 thread for both) there are still 300k in favor of openMP which, normally, it should be slower than the non-omp version.
Can you think of *any* other parameters which are tweakable and (may) lead to the +300k gain for the omp version? I want to try various stuff but I don't know what to tweak. My rationale is that if the non-omp version is running with at least the same parameters of the omp version, then the non-omp could be slightly faster than the omp-version (I'm always talking about 1 thread) perhaps exceeding 4.8-4.9m c/s instead of being near the 4.5m mark.
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.
