[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Sat, 15 Dec 2012 19:43:30 +0100
From: magnum <john.magnum@...hmail.com>
To: john-dev@...ts.openwall.com
Subject: Re: Benchmark versus incremental mode (speed)
On 15 Dec, 2012, at 15:40 , Claudio André <claudioandre.br@...il.com> wrote:
> Em 14-12-2012 23:55, Claudio André escreveu:
>> Per definition, the real crack gives the real figure. If they differ
>> it may be due to things like test vector length not matching the IRL
>> run (in case the format suffers significantly from length) or if the
>> IRL hash does not use 5000 iterations. If that's not it, I'm not sure.
>
> It is test vector dependant (the patch below increases bench numbers). Since, i'm not sure how to produce a fair test vector, i won't do anything.
I just remembered one more parameter, that is GPU specific: If your kernel has branches (not sure if your has), a crypt_all() where all candidates are the exact same (i.e. only one single test vector present) or otherwise will branch the same, it will run faster than the real case where the branches will result in diverging threads. This can be seen with the RAR format. In that case, a crypt_all() with uniform length candidates will run faster than one with mixed lengths.
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.
