[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 06 Jul 2015 01:15:54 +0200
From: magnum <john.magnum@...hmail.com>
To: john-dev@...ts.openwall.com
Subject: Re: PHC: Lyra2 on GPU
On 2015-07-05 08:09, Solar Designer wrote:
> On Sun, Jul 05, 2015 at 01:42:41AM +0200, magnum wrote:
>> Something like this perhaps?
>>
>> void reset(struct db_main *db)
>> {
>> static int tuned_already;
>>
>> if (db || (options.flags & FLG_TEST_SET)) {
>> /* look at db for costs, then autotune here */
>> tuned_already = 1;
>> }
>> else if (!tuned_already) {
>> /* set a fixed low LWS & GWS here */
>> }
>> }
>>
>> So if we're running --test, we'll auto-tune at first call to reset() and
>> not re-tune at second call.
>>
>> If running an actual crack, we'll self-test with some low LWS/GWS (eg.
>> 8/64) and then once we get a db (which we can look at to see costs)
>> we'll auto-tune for actual costs.
>>
>> It would be slightly safer to self-test using the actual LWS/GWS that
>> will be used later, but iirc this can't be done without changing core.
>
> Yes, right, but you may make or propose specific changes to make this
> possible.
Thinking loud. Current behavior, for a test run we have:
reset(NULL)
self-tests
benchmarks
And for a crack run we have:
reset(NULL)
self-tests
reset(db)
crack mode
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.
A test run would be effectively the same. A crack run would become:
reset(db)
self-tests
reset(db)
crack mode
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?
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.
