[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20140325201137.GA11138@openwall.com>
Date: Wed, 26 Mar 2014 00:11:37 +0400
From: Solar Designer <solar@...nwall.com>
To: john-users@...ts.openwall.com
Subject: Re: Re: john-1.8.0-Win-32 - john.omp.exe - cores used
PhanTom,
Please consider joining the mailing list and posting via e-mail, instead
of continuing to post via Gmane.
On Tue, Mar 25, 2014 at 07:54:35PM +0000, -. -PhanTom-. - wrote:
> Yup, this one: http://openwall.info/wiki/_media/john/john-1.8.0-Win-32.zip
>
> Intel i5-4670K (stock), 16Gb RAM, Windows7 Home Premium
>
> The rest of the tests for the 1.8.0Win32 build shows:
> H:\HA\john-1.8.0-Win-32>john-omp -t
> Will run 4 OpenMP threads
> Benchmarking: descrypt, traditional crypt(3) [DES 128/128 SSE2]... DONE
> Many salts: 4683K c/s real, 4790K c/s virtual
> Only one salt: 4512K c/s real, 4509K c/s virtual
>
> Benchmarking: bsdicrypt, BSDI crypt(3) ("_J9..", 725 iterations) [DES 128/128 SS
> E2]... DONE
> Many salts: 158831 c/s real, 158879 c/s virtual
> Only one salt: 154524 c/s real, 155210 c/s virtual
This suggests that the build is slightly broken. Oops. Specifically,
my guess is that this condition was triggered during build:
#if DES_BS_ASM && defined(_OPENMP) && defined(__GNUC__)
#warning Assembly code and OpenMP are both requested - will provide the former, but not the latter (for DES-based hashes). This may likely be corrected by enabling SIMD intrinsics with the C compiler (try adding -msse2 to OMPFLAGS).
#endif
but the warning was ignored. Normally, when building for 32-bit x86 and
wanting OpenMP, one would uncomment this line in the Makefile:
# gcc with OpenMP on 32-bit x86 with SSE2
#OMPFLAGS = -fopenmp -msse2
but I guess this was not done. I guess only this line was uncommented:
# gcc with OpenMP
#OMPFLAGS = -fopenmp
> Benchmarking: md5crypt [MD5 32/32]... DONE
> Raw: 36132 c/s real, 9882 c/s virtual
>
> Benchmarking: bcrypt ("$2a$05", 32 iterations) [Blowfish 32/32 X2]... DONE
> Raw: 3618 c/s real, 945 c/s virtual
This shows that OpenMP works for these other hash types, confirming the
guess above. (For md5crypt, jumbo will give better speeds.)
> The john179j5w build seems to work for all four cores, although the speed is
> not X4 for DES...?
> john179w2 also use all four cores :)
Great. How much lower than x4 is the speed for DES crypt? Is it closer
to x4 for BSDI DES (it should be)?
The issue is that with fast(er) hashes, our parallelization with OpenMP
has significant overhead. Additionally, for our bitslice DES code when
going for OpenMP we switch from hand-optimized non-thread-safe x86+SSE2
assembly code to compiler-generated thread-safe code.
In 1.8+, we recommend the --fork option for those since it has higher
efficiency, but it's not reliably supported on Windows (in fact, it's
disabled by default on Windows, in os.h, because of reported problems).
Overall, you'd get better results on a Unix-like system. I admit this
is in part because of shortcomings in JtR's support for Windows.
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.
