[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <aaf9fcf44d185e200478915352b142f5@smtp.hushmail.com>
Date: Wed, 07 Mar 2012 00:31:27 +0100
From: magnum <john.magnum@...hmail.com>
To: john-dev@...ts.openwall.com
Subject: Re: OpenCL KPC and LWS
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.
> 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
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.
