[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20100509122150.GA12948@openwall.com>
Date: Sun, 9 May 2010 16:21:50 +0400
From: Solar Designer <solar@...nwall.com>
To: john-users@...ts.openwall.com
Subject: Re: OpenMP
On Sun, May 09, 2010 at 07:18:50AM -0400, Erik Winkler wrote:
> Patch compiles and works flawlessly on MacOS 10.6 as OpenMPI is part of the OS. CPU is a Intel "Core 2 Duo" "Penryn" (P8600).
The patch uses OpenMP, which is part of recent versions of gcc. It does
not use Open MPI.
Can you check what libraries the resulting "john" binary is linked
against and what directories those are in? On Linux, I am getting:
$ ldd john
libgomp.so.1 => /home/solar/gcc-4.5.0/lib64/libgomp.so.1 (0x00002b64f231c000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x00002b64f242c000)
libc.so.6 => /lib64/libc.so.6 (0x00002b64f2541000)
librt.so.1 => /lib64/librt.so.1 (0x00002b64f2766000)
/lib64/ld-linux-x86-64.so.2 (0x00002b64f2207000)
The dependency on libgomp.so.1 in my gcc install tree means that this
binary won't work on a system without a similar gcc install. Of course,
I can simply add -static to LDFLAGS, which removes all of those runtime
dependencies on external libraries - I actually did just that to test
performance on other Linux machines (with different CPUs).
I wonder if your "john" binary on Mac OS X is dependent on having Xcode
installed or not. And if it is, does adding -static work (produce a
working fully-static binary)? This is going to be important for those
using binary builds of JtR for Mac OS X, many of whom do not have Xcode
installed (I guess).
It might be better to attempt a "half-static" build, though - link
libgomp statically, but the rest dynamically. I am doing it this way
for OpenSSL in JtR Pro (libcrypto gets linked in statically).
> ./john -test -format:bf
> Benchmarking: OpenBSD Blowfish (x32) [32/64 X2]... DONE
> Raw: 1211 c/s real, 627 c/s virtual
It's nice to see that the number of logical CPUs is detected correctly,
just like it is on Linux.
To see how efficient this build is, you need to compare the 1211 c/s
figure vs. combined c/s rate for two separate "john" processes built
without OpenMP (JtR 1.7.5 without any patch). You'd need to run those
two simultaneously, with a script like:
./john -te -fo=bf &
./john -te -fo=bf &
Note that setting OMP_NUM_THREADS=1 does not fully regain the
performance of a non-OpenMP build. Some overhead remains - mostly
resulting from the code having to reference the "Blowfish context" data
structure through a pointer rather than have it at a fixed address.
> This would be very useful for other hash types as well.
Yes, although I do not expect to achieve a 98.5% efficiency for faster
hashes. We'll see.
Thank you for testing!
Alexander
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.
