[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 07 Mar 2012 10:03:35 +0100
From: Samuele Giovanni Tonon <samu@...uxasylum.net>
To: john-dev@...ts.openwall.com
Subject: Re: OpenCL KPC and LWS
On 03/07/12 00:31, magnum wrote:
> On 03/06/2012 11:39 PM, Samuele Giovanni Tonon wrote:
>> On 03/06/12 20:14, magnum wrote:
>>> Also, I seem to get good and very fast results with this loop in KPC
>>> enumeration:
>>>
>>> for( num=local_work_size; num <= SSHA_NUM_KEYS ; num<<=1)
>>>
>>>
>>> Is testing every 16K really of any use? I just see fluctuating numbers
>>> and a super slow test.
>>
>> this was the idea i had in mind: by default you will get SSHA_NUM_KEYS,
>> which is the standard, if you set KPC=0 it means you want to do a deep
>> benchmark on which could be the real best kpc; 16384 seemed a reasonable
>> tradeoff between having a very long but detailed benchmark rather 3-4
>> test which could be misleading.
>
> Fair enough. The real problem I have with this is when running CPU. The
> default KPC is WAY too high and the current KPC enumeration is way too
> slow. Maybe we could adopt the enumeration if we are running on CPU.
>
> BTW both the LWS and KPC functions should ideally move to opencl-common.
yes i agree, unfortunately there's the "hashing" and prepare part in
those function which vary from format to format, shall we use a
commong function in opencl-common and put a pointer function as arg ?
>> i'm still testing it: on the others format the step is 4096 but
>> *_NUM_KEYS is 1024*2048, on nsldaps i found 1024*2048*4 was giving
>> higher speed with high end cards so i decided to keep a high value but
>> incrementing the steps to not die of boredom (as it already happens).
>> i'm still looking for the best number for the steps, while doubling
>> seems good for a quick benchmark i still think many cards find the best
>> kpc between 1024*1024 and 1024*1024*2 , steps that the doubling miss.
>
> BTW If you enumerate a good KPC and LWS for one format, they may not be
> the same for another so exporting the environment variable does not
> solve the problem. In the end we could end entries in john.conf:
> [OpenCL options]
> platform = 1
> device = 0
> ssha_LWS = 512
> ssha_KPC = 8192
> phpass_LWS = ...
>
> This is very easy, there are helper functions at your service and they
> support having a default unless a figure is present. This way I could
> stand doing a very long test because I would not have to do it again
> after putting the figures in john.conf
>
> I suppose we should take the first we find of these:
> 1. environment variable (for over-riding john.conf)
> 2. john.conf entry
> 3. default hard-coded value
yes that's exactly what i had in mind but without the entry in john.conf
(i'm still trying to not modify non opencl code). in that way you can
call john like this:
export LWS=64
export KPC=1024768
./john -i:all -fo:ssha-opencl /tmp/myhashes
export LWS=128
export KPC=2097152
./john -i:all -fo:mysql-sha1-opencl /tmp/pw-mysql
of course if we can add that to john.conf that would be wonderful
the only problem is, how to trigger the benchmark so then you can
write down best numbers and never do that again ? we could behave like now:
- lws il always tested until it's put in john.conf
- kpc is at max_kpc until you put as 0 in john.conf, get the best value
for your card and fix the value in john.conf
will it work ?
Cheers
Samuele
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.
