|
Message-ID: <20120725123016.GA585@openwall.com> Date: Wed, 25 Jul 2012 16:30:16 +0400 From: Solar Designer <solar@...nwall.com> To: john-dev@...ts.openwall.com Subject: Re: Result of hard core password generation on 7970 myrice - On Wed, Jul 25, 2012 at 06:12:00PM +0800, myrice wrote: > Here is the new rough result > > 1: with 2048*8, ~900M c/s, but with 2048*16, it is ~500M c/s OK, this is starting to become reasonable. Have you also tried values smaller than 2048*8? > 1000: with 2048*8, ~45G = ~45M, with 2048*16, ~90G = ~ 45M I understand what you mean by "~45G = ~45M", but why "~90G = ~ 45M"? I think you're confused. At 1000 same-salt hashes, "90G" reported effective speed (combinations per second) means 90M hashes computed per second. max_keys_per_crypt is not part of that equation. (I definitely need to improve speed reporting to avoid such confusion.) > 1M: still cannot get, I reduce the global work size to 128 and only > append[a-e][a-e], it is very slow. And the kernel cannot finished with > [a-z][a-z]. > > I am think about compare, with 1M hashes, the loop inside one thread > increased to 26*26*1M = 676M, it is very large for a thread. As discussed, you absolutely must implement bitmaps and hash tables on GPU. Your direct comparisons are only good for very small numbers of loaded hashes and for early experiments with larger numbers, like what you're doing now. As you've reached this milestone, you should now proceed further - to bitmaps and hash tables. 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.