Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Sat, 15 Dec 2012 19:43:30 +0100
From: magnum <>
Subject: Re: Benchmark versus incremental mode (speed)

On 15 Dec, 2012, at 15:40 , Claudio André <> 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.


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.