|
Message-ID: <20120403130722.GA15658@openwall.com> 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.