Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 30 Mar 2015 13:38:51 +0300
From: Solar Designer <>
Subject: Re: [GSoC] John the Ripper support for PHC finalists

On Mon, Mar 30, 2015 at 12:17:25PM +0200, magnum wrote:
> On 2015-03-30 12:02, Solar Designer wrote:
> > 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,

Actually, POMELO v2 includes 256-bit SIMD parallelism (v1 did not).
This is sufficient for current CPUs.

POMELO v2 still tries to discourage SIMD wider than that.

> > 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.
> AMD's CPU driver never prints such warnings, and it never reports
> succesful auto-vectorization either. Actually I'm not convinced it does
> auto-vectorizing at all. I have a few formats that adopt to the device's
> reported "best vector width" with pre-vectorized code and the AMD driver
> usually respond very well to that iirc.
> Anyway the speed difference is almost 15x, that wouldn't be explained
> with vectorizing alone.



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.