Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Fri, 27 Apr 2012 01:13:55 +0200
From: magnum <john.magnum@...hmail.com>
To: john-dev@...ts.openwall.com
Subject: Re: New RAR OpenCL kernel

On 04/27/2012 12:40 AM, Solar Designer wrote:
> On Thu, Apr 26, 2012 at 11:29:43PM +0200, magnum wrote:
>> But with sane durations (like 3 secs @16K GWS) I now have ~4500 c/s on
>> GTX570/580 as well as HD 7970.
> 
> That's very nice.  There ought to be much room for improvement on the
> 7970, though.

For GTX5x0 too, but even more for 7970. By the way, GTX680 is slower
than GTX580 on the few things I have tested. So much for that flagship.
At least for GPGPU, AMD is still the leader I guess.

>> [...] I'm now trying to figure out how
>> to make the host code "sort" the lengths in some effective way. I got a
>> vague idea: What if I launch all applicable kernels at once (the host
>> code may decide that we need kernels for eg. length 4, 5 and 6) after
>> the host code sets up an array with pointers for each length
>> accordingly. I think this would be fairly cheap in this context.
> 
> Why not just run the per-length kernels sequentially, out of one call to
> crypt_all()?  Do you prefer to run them in parallel because there would
> be less than the full number of passwords with some lengths, and you
> want to compensate for that?  Maybe only run 2+ kernels at a time in
> this special case (too few passwords with a given length)?

I'd have to experiment with that, but it seems natural to me to just
launch all of them without waiting for any previous. I guess I should
interleave transfers and launches though.

Context switches in GPU are not only cheap, they are a fundamentally
good thing if I understand things right. Actually I would think running
4 kernels in parallel with 4K each would hide latency just as well as 1
kernel with 16K so I might not even have to buffer more keys. But I
could very well be wrong.

magnum

Powered by blists - more mailing lists

Your e-mail address:

Powered by Openwall GNU/*/Linux - Powered by OpenVZ