[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20130809145345.GA493@openwall.com>
Date: Fri, 9 Aug 2013 18:53:45 +0400
From: Solar Designer <solar@...nwall.com>
To: john-dev@...ts.openwall.com
Subject: Re: Intel OpenCL on CPU and MIC
On Fri, Aug 09, 2013 at 04:03:56PM +0200, magnum wrote:
> On 8 Aug, 2013, at 23:32 , Solar Designer <solar@...nwall.com> wrote:
> > -cl-strict-aliasing was not understood by (and resulted in errors from) Intel's OpenCL compiler. (Should we make this change standard?)
>
> This is a violation of OpenCL, that option is mandatory ever since 1.0 afaik. We can drop it for now but we should probably use it selectively - some compilers may produce faster code with this option, right?
Maybe. I'm not familiar with the OpenCL option, but from my experience
gcc's -fstrict-aliasing almost never results in faster code, although it
theoretically might.
> > I am getting roughly the same cumulative speed by building the whole JtR right for Xeon Phi and running it there. No OpenMP that way for a subtle reason that I can explain separately, but I did run with --fork=228, for a cumulative speed at bcrypt of around 6000 c/s.
>
> A good speed would be at least 10x that, no?
It could be. With vectorized code, the limiting factor would be L1
cache size, and moreover tricks would probably need to be used to avoid
exceeding that size. (I'm not sure, but I think MIC supports
conditional processing of each vector element. The newer AVX-512
certainly does.)
> What could be the reason for such a low figure?
Lack of vectorization.
> What speed do you get from one core?
Cross-compile with icc from host, running directly on the MIC card:
Benchmarking: bcrypt ("$2a$05", 32 iterations) [Blowfish 32/64 X2]... DONE
Raw: 67.1 c/s real, 67.1 c/s virtual
This is 1 process, on one of the 228 logical CPUs. 1.1 GHz.
I'd say this is a bit low - but only a little bit. Maybe my ancient
Pentium assembly code will run faster, since Xeon Phi reuses P54C cores
(with some updates, including to 64-bitness - but 64-bitness is not
helpful for bcrypt).
Like I said, the cumulative speed of 228 such processes is about 6000 c/s,
so roughly the same as we get with OpenCL.
More single-process speeds, without intrinsics, 1-second benchmarks:
Benchmarking: descrypt, traditional crypt(3) [DES 64/64]... DONE
Many salts: 185411 c/s real, 187247 c/s virtual
Only one salt: 180720 c/s real, 180720 c/s virtual
Benchmarking: bsdicrypt, BSDI crypt(3) ("_J9..", 725 iterations) [DES 64/64]... DONE
Many salts: 6400 c/s real, 6400 c/s virtual
Only one salt: 6337 c/s real, 6337 c/s virtual
Benchmarking: md5crypt [MD5 32/64 X2]... DONE
Raw: 1407 c/s real, 1407 c/s virtual
Benchmarking: bcrypt ("$2a$05", 32 iterations) [Blowfish 32/64 X2]... DONE
Raw: 66.6 c/s real, 66.6 c/s virtual
Benchmarking: LM [DES 64/64]... DONE
Raw: 3231K c/s real, 3231K c/s virtual
Benchmarking: AFS, Kerberos AFS [DES 48/64 4K]... DONE
Short: 40300 c/s real, 40300 c/s virtual
Long: 133069 c/s real, 133069 c/s virtual
Benchmarking: tripcode [DES 64/64]... DONE
Raw: 169353 c/s real, 169353 c/s virtual
Benchmarking: dummy [N/A]... DONE
Raw: 8578K c/s real, 8578K c/s virtual
Benchmarking: crypt, generic crypt(3) [?/64]... DONE
Many salts: 30400 c/s real, 30400 c/s virtual
Only one salt: 30494 c/s real, 30494 c/s virtual
With 512-bit MIC intrinsics (except for key setup since I did not bother
encoding the shift counts into vectors yet):
Benchmarking: descrypt, traditional crypt(3) [512/512]... DONE
Many salts: 619419 c/s real, 619419 c/s virtual
Only one salt: 561679 c/s real, 561679 c/s virtual
Benchmarking: bsdicrypt, BSDI crypt(3) ("_J9..", 725 iterations) [512/512]... DONE
Many salts: 21374 c/s real, 21374 c/s virtual
Only one salt: 20380 c/s real, 20380 c/s virtual
Benchmarking: LM [512/512]... DONE
Raw: 6816K c/s real, 6816K c/s virtual
Benchmarking: tripcode [512/512]... DONE
Raw: 481882 c/s real, 481882 c/s virtual
Somehow got faster bcrypt in this build:
Benchmarking: bcrypt ("$2a$05", 32 iterations) [Blowfish 32/64 X2]... DONE
Raw: 70.5 c/s real, 70.5 c/s virtual
Like I mentioned, the cumulative speed at descrypt for 228 processes is
around 67M c/s, although in a longer run I observed almost 70M c/s.
For md5crypt, the cumulative speed is around 150k c/s. Not good, but
that's without SIMD yet - we should add MIC SIMD intrinsics to
sse-intrinsics.c.
> I'm hoping I will find time to start experimenting on 'well' within a few weeks.
Note that there's no Xeon Phi in "well" yet. We still haven't managed
to solve the motherboard incompatibility issue - might need to setup a
new machine for the Xeon Phi card.
The above tests are on Microway's Xeon Phi system, which they kindly
provided me with access to (for a week, so I won't be able to do much
more on it).
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.
