[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 06 Jul 2015 23:21:32 +0200
From: magnum <john.magnum@...hmail.com>
To: john-dev@...ts.openwall.com
Subject: Re: reset(db) before self-test (was: PHC: Lyra2 on GPU)
On 2015-07-06 21:02, Agnieszka Bielec wrote:
> 2015-07-06 20:48 GMT+02:00 magnum <john.magnum@...hmail.com>:
>> On 2015-07-06 18:53, Agnieszka Bielec wrote:
>>>
>>> 2015-07-06 10:25 GMT+02:00 Solar Designer <solar@...nwall.com>:
>>>>
>>>> On Mon, Jul 06, 2015 at 01:15:54AM +0200, magnum wrote:
>>>>>
>>>>> We could change it to always pass "db" to reset(). It could still *be*
>>>>> NULL but we'd never call it with an explicit NULL.
>>>>> (...)
>>>>> This would solve this issue but a side-effect is reset() can no longer
>>>>> tell whether we're about to self-test before a crack or actually run
>>>>> one. For resolving that we could simply change
>>>>>
>>>>> void fmt_reset(struct db_main *db);
>>>>>
>>>>> ...to
>>>>>
>>>>> void fmt_reset(struct db_main *db, int self_test);
>>>>>
>>>>> ...and a crack run would change to:
>>>>> reset(db, 1)
>>>>> self-tests
>>>>> reset(db, 0)
>>>>> crack mode
>>>>>
>>>>> Does this make sense?
>>>>
>>>>
>>>> Yes, this makes sense to me. Would we actually need to add this "int
>>>> self_test"? The few formats that care would be able to count the
>>>> reset() calls on their own, perhaps with the counter reset on init().
>>>
>>>
>>> first printf() is in opencl_init, second in autotune_run()
>>> maybe just modify these functions to only printf once and call these
>>> functions as now it looks like in the code?
>>
>>
>> If I understand you right, you are looking at hiding the problem instead of
>> fixing it?
>
> the problem is only that something is printf'ed 2 times and user can
> be confused (as I think) or there is something more?
That was not quite the problem, but a symptom resulting from it. You did
nothing wrong but you lead us to see a limitation in core code.
> opencl_init can be moved to init (if build_opts aren't changing), and
> maybe i can not-autotune for tests but I was just thinking about
> something else
Yes there are ways to work around this within your reset function but
that would mean the self-tests would use different LWS/GWS from what
would then be used for the actual crack - so the self-tests would be in
a much worse position to detect problems.
What we're discussing above applies to Lyra2 as well as many other
formats (including Pomelo). After the above is implemented (I'll try it
out soon) you will be able to auto-tune for correct cost(s) once and for
all, *before* self-tests.
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.
