Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <50FAABC9.8010204@gmail.com>
Date: Sat, 19 Jan 2013 12:20:57 -0200
From: Claudio André <claudioandre.br@...il.com>
To: john-dev@...ts.openwall.com
Subject: Re: New shared find_best_gws

Em 19-01-2013 11:30, magnum escreveu:
> On 16 Jan, 2013, at 3:38 , Claudio André <claudioandre.br@...il.com> wrote:
>> Hi, i created a new shared find_best_GWS.
>>
>> It uses:
>> - format->set_salt, format->set_key, format->crypt_all, etc.
>> - requires create_clobj and release_clobj (you have to give pointers to them so find_best_GWS can (m)alloc necessary memory).
>> - (maybe) a new crypt_all_benchmark function (with unique events for all OpenCL commands).
>>
>> It can handle a set of formats for sure. Anyway, it will be nice if new formats authors try it (at least to show its problems).
>>
>> As usual, you can dance naked using legacy code and it still works.
>
> Good stuff. I see you also added a opencl_find_best_lws() function. Is that a new version of opencl_find_best_workgroup() with more flexibility (eg. for split-kernel formats)?

Yes and no. While probing GWS you need a crypt_all function 'with a 
specific style'. I thought it is better to unify in this case.


> I think we might want to adopt core JtR style and move/add comments to common-opencl.h. For example, this comment in the .c file might be better put in the .h file:
>
> /*
>   *   NOTE: Requirements for using this function:
>   *
>   * - Your kernel (or main kernel) should be crypt_kernel.
>   * - Use profilingEvent in your crypt_all() when enqueueing crypt_kernel.
>   * - Do not use profilingEvent for transfers or other subkernels.
>   * - For split kernels, use firstEvent and lastEvent instead.
>   */
>
> And similar how-to comments should be added for some/many of the other functions. For deprecated functions (which we might end up making static or rationalize away eventually) we could point to the newer/better alternative. Obviously we shouldn't bother with this for unstable, only bleeding.
>
> This would be of great help for developers trying to catch up, including myself!
>
> magnum

I would go further, john-dev should enforce patterns of naming, of 
commenting, of style, etc.

What about open tickets for every detail that matters and keep this 
information available? Not coder guys can help here.

Claudio

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.