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