|
Message-ID: <loom.20051222T022115-888@post.gmane.org> Date: Thu, 22 Dec 2005 01:42:51 +0000 (UTC) From: Radim Horak <yesbody@...nam.cz> To: john-users@...ts.openwall.com Subject: Re: john improvement suggestions - vc compilation test Solar Designer <solar@...> writes: > I really don't think that the performance improvement you've observed is > related to this compiler producing better code (I do not know whether > that is the case). LM_fmt.c is not really performance critical. For LM > hashes on x86/MMX, the performance critical code is primarily in DES_bs.c > and indeed in x86-mmx.S. ... > Can you provide the specific "john --test" outputs for both builds and > tell us your CPU clock rate (real and P4 rating)? 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 params.h: BENCHMARK_TIME 30 (didn't help much) bench.c: removed cygwin check $ ./john -t Benchmarking: Traditional DES [64/64 BS MMX]... DONE Many salts: 753235 c/s real, 813754 c/s virtual Only one salt: 683485 c/s Benchmarking: BSDI DES (x725) [64/64 BS MMX]... DONE Many salts: 24927 c/s real, 27091 c/s virtual Only one salt: 24077 c/s Benchmarking: FreeBSD MD5 [32/32]... DONE Raw: 5643 c/s real, 6252 c/s virtual Benchmarking: OpenBSD Blowfish (x32) [32/32]... DONE Raw: 335 c/s real, 346 c/s virtual Benchmarking: Kerberos AFS DES [48/64 4K MMX]... DONE Short: 141239 c/s real, 156198 c/s virtual Long: 528674 c/s Benchmarking: NT LM DES [64/64 BS MMX]... DONE Raw: 5745K c/s real, 6318K c/s virtual ------------------- ms vc2003 method: cl /c /TC /G7 /Ox /O2 /Zl /arch:SSE /FoDES_fmt.o DES_fmt.c cl /c /TC /G7 /Ox /O2 /Zl /arch:SSE /FoDES_std.o DES_std.c cl /c /TC /G7 /Ox /O2 /Zl /arch:SSE /FoDES_bs.o DES_bs.c cl /c /TC /G7 /Ox /O2 /Zl /arch:SSE /FoBSDI_fmt.o BSDI_fmt.c cl /c /TC /G7 /Ox /O2 /Zl /arch:SSE /FoMD5_fmt.o MD5_fmt.c cl /c /TC /G7 /Ox /O2 /Zl /arch:SSE /FoMD5_std.o MD5_std.c cl /c /TC /G7 /Ox /O2 /Zl /arch:SSE /FoBF_fmt.o BF_fmt.c cl /c /TC /G7 /Ox /O2 /Zl /arch:SSE /FoBF_std.o BF_std.c cl /c /TC /G7 /Ox /O2 /Zl /arch:SSE /FoAFS_fmt.o AFS_fmt.c cl /c /TC /G7 /Ox /O2 /Zl /arch:SSE /FoLM_fmt.o LM_fmt.c rem copy *.o to the src directory rem make WITHOUT clean make win32-cygwin-x86-mmx $ ./john -t Benchmarking: Traditional DES [64/64 BS MMX]... DONE Many salts: 748780 c/s real, 812828 c/s virtual Only one salt: 672553 c/s Benchmarking: BSDI DES (x725) [64/64 BS MMX]... DONE Many salts: 25094 c/s real, 27090 c/s virtual Only one salt: 24464 c/s Benchmarking: FreeBSD MD5 [32/32]... DONE Raw: 5667 c/s real, 6188 c/s virtual Benchmarking: OpenBSD Blowfish (x32) [32/32]... DONE Raw: 334 c/s real, 364 c/s virtual Benchmarking: Kerberos AFS DES [48/64 4K MMX]... DONE Short: 140758 c/s real, 156105 c/s virtual Long: 503631 c/s Benchmarking: NT LM DES [64/64 BS MMX]... DONE Raw: 6514K c/s real, 7152K c/s virtual -------------------------------- The improvement seems to be more than just luck, the repeated testing shows it is consistent. The most important/critical vc option for improving LM performance seems to be "/arch:SSE" which unfortunately slipped from my original post. > Overall, I do not see a need to support building John with MSVC. That > would complicate the code with more #ifdef's for no good reason. > 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. However I am interested in optimizing compilation, though my understanding of source code and programming skills are very limited :) -Radim
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.