john-users - Re: Re: john improvement suggestions

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sat, 31 Dec 2005 06:42:34 +0300
From: Solar Designer <solar@...nwall.com>
To: john-users@...ts.openwall.com
Subject: Re:  Re: john improvement suggestions - vc compilation test

On Thu, Dec 22, 2005 at 01:42:51AM +0000, Radim Horak wrote:
> My CPU: AthlonXP (Barton) 2.2 GHz (PR 3200+)
> 
> john 1.6.40
> gcc 3.4.4
> target: win32-cygwin-x86-mmx
> 
> edited:  
> Makefile: CFLAGS = -c -Wall -O4 -funroll-loops -fomit-frame-pointer -
> march=athlon-xp -mtune=athlon-xp
[...]
> Benchmarking: NT LM DES [64/64 BS MMX]... DONE
> Raw:    5745K c/s real, 6318K c/s virtual
> 
> -------------------
> ms vc2003
[...]
> cl /c /TC /G7 /Ox /O2 /Zl /arch:SSE /FoDES_bs.o DES_bs.c
[...]
> Benchmarking: NT LM DES [64/64 BS MMX]... DONE
> Raw:    6514K c/s real, 7152K c/s virtual

OK, I am willing to believe that the speedup is caused by your
recompiling DES_bs.c with better optimizations.  The key setup functions
from that source file should be re-coded in assembly for x86.  I might
do that eventually.

> The improvement seems to be more than just luck, the repeated testing shows it 
> is consistent.

Not really.  I don't think you were trying to change the relative
placement of the object files within your compiled executable.

To provide a somewhat extreme example: merely adding a few kilobytes of
unused padding to the DES_bs_all struct changes the performance at LM
hashes by as much as 40% on my Alpha.  This is for data placement.  But
the same could easily apply to code placement.  Of course, as I have
mentioned before, Alphas are far more susceptible to this because of
their use of direct-mapped caches.

> The most important/critical vc option for improving LM 
> performance seems to be "/arch:SSE"

Hardly, unless you've actually tested with/without this option before
you came to this conclusion.

> Personally I am not interested in LM in john, I just wanted to share this 
> discovery :) with others, who can compile it themselves. Maybe someone can 
> figure out the details of this behaviour and make good use of them. 

OK.

Thanks,

-- 
Alexander Peslyak <solar at openwall.com>
GPG key ID: B35D3598  fp: 6429 0D7E F130 C13E C929  6447 73C3 A290 B35D 3598
http://www.openwall.com - bringing security into open computing environments