Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 05 Jul 2012 15:19:15 -0300
From: Claudio André <>
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:

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.