[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 05 Jul 2012 15:19:15 -0300
From: Claudio André <claudioandre.br@...il.com>
To: john-dev@...ts.openwall.com
Subject: Re: [private] common find_best_workgroup()
Not sure it deserves such attention. If you get rid of
find_best_workgroup, everybody can play with something similar just trying:
LWS=32
LWS=64
LWS=128
Maybe 2 options on CPU (1 and 8).
It is to much work to deal with a few (32 or 64 or 128) options. No?
Em 05-07-2012 14:56, magnum escreveu:
> On 2012-07-05 16:23, magnum wrote:
>> I have already committed an experimental fix. Seems to work fine but
>> still testing (I also changed all formats except Claudio's so they use
>> the shared function)
> I reverted this change (using a shared find_best_workgroup() ) for
> opencl_xsha512_fmt.c because it had a "special" loop in its local one:
> it runs each size 10 times and sums the exec time. And its performance
> got worse (selecting a lower LWS) with the shared one.
>
> This gave me this idea (to-do) for the shared one:
>
> 1. perform a warm-up run of crypt_all() before the loop, but check the
> exec time.
> 2. From that exec time, chose a suitable number of loops (targeting a
> minimum sum of exec times)
> 3. Do wot myrice did, using that number of loops.
>
> This might greatly reduce the "randomness" I have experienced with
> find_best(). And when this is implemented, opencl_xsha512_fmt.c can get
> on this train too again :)
>
> 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.
