[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 3 Apr 2012 17:07:22 +0400
From: Solar Designer <solar@...nwall.com>
To: john-dev@...ts.openwall.com
Subject: Re: fast hashes on GPU
On Tue, Apr 03, 2012 at 06:05:19PM +0800, myrice wrote:
> Now, I have already implemented the keys_changed trick. When no key is
> changed, the keys will remain on GPU and will not invoke cudaMemcpy
> function.
Great. I'll test your newer code on my GTX 570 later.
> Next step, I will implement salts optimizations(the lengthy one).
You may want to consider offloading the hash comparisons onto the GPU
first. I expect that this will provide greater speedup than the salts
thing. The approach to implementing it is similar.
For salts, you'd only achieve an effect very similar to what you'd
achieve by simply using a much larger max_keys_per_crypt value (more
work done per one interaction with GPU). Thus, I expect that with or
without the salts trick, you'd achieve similar performance as long as
max_keys_per_crypt is properly tuned for each case separately.
> Here are benchmarks:(I will put on my github later)
> ---------Before keys_changed trick-----------------------
> Benchmarking: Mac OS X 10.7+ salted SHA-512 CUDA [64/64]... DONE
> Many salts: 1080K c/s real, 1086K c/s virtual
> Only one salt: 1056K c/s real, 1059K c/s virtual
> ---------After keys_changed trick--------------------------
> Benchmarking: Mac OS X 10.7+ salted SHA-512 CUDA [64/64]... DONE
> Many salts: 1134K c/s real, 1134K c/s virtual
> Only one salt: 1092K c/s real, 1092K c/s virtual
>
> As I expected, this doesn't give a lot performance. Observations from cuda
> profiler also provide that cudaMemcpy occupies a little time during crack.
I think this same change will make a lot more of a difference on a
faster GPU.
Thanks,
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.
