[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20150330100245.GA26901@openwall.com>
Date: Mon, 30 Mar 2015 13:02:45 +0300
From: Solar Designer <solar@...nwall.com>
To: john-dev@...ts.openwall.com
Subject: Re: [GSoC] John the Ripper support for PHC finalists
On Mon, Mar 30, 2015 at 10:24:45AM +0300, Solar Designer wrote:
> So the speed of C code is maybe good - I say maybe because we don't know
> yet how much better it can be made. One of two OpenCL SDKs running on
> the CPUs achieves about the same speed, which is a good sanity check.
> The other fails to vectorize the code, resulting in much lower speed.
Actually, the failure to vectorize is possibly a red herring. POMELO is
designed to be somewhat SIMD-unfriendly, including in attack
implementations (with extra parallelism from having multiple candidate
passwords). So I doubt the other OpenCL SDK vectorized it; perhaps it
just didn't print the warning. This needs to be looked into for real.
> The speed on Xeon Phi via OpenCL is a joke, but that's not too
> surprising given that OpenCL isn't currently a good way to program Xeon
> Phi (Intel's OpenCL implementation for Xeon Phi is too poor). On AMD
> GPU, the performance is low - this needs to be looked into. On NVIDIA,
> the kernel fails to compile.
The poor speeds on GPUs may actually be fine, indicating POMELO's
success at being GPU-unfriendly, but we need to try and optimize the
OpenCL kernels and their settings before we possibly arrive at this
conclusion. Also, need to test across ranges of POMELO cost settings.
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.
