Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <93fda567db1f7bf7759a10b41b4cdb4a@smtp.hushmail.com>
Date: Mon, 30 Mar 2015 12:17:25 +0200
From: magnum <john.magnum@...hmail.com>
To: john-dev@...ts.openwall.com
Subject: Re: [GSoC] John the Ripper support for PHC finalists

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, 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.

magnum

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.