[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <9f42274e1d84f25e3fe71fcdbaeb4e17@smtp.hushmail.com>
Date: Fri, 03 Apr 2015 20:32:34 +0200
From: magnum <john.magnum@...hmail.com>
To: john-dev@...ts.openwall.com
Subject: Re: [GSoC] John the Ripper support for PHC finalists
On 2015-04-03 20:03, Agnieszka Bielec wrote:
> 2015-04-03 18:17 GMT+02:00 magnum <john.magnum@...hmail.com>:
>> I still think you should set things up in reset(db != NULL) at which
>> point costs will be known. Did you miss my mail
>> http://www.openwall.com/lists/john-dev/2015/03/30/17 ?
>
> I see but it's only auto tuning, I don't want to compile the kernel
> many times.
> I think that I must to generate fmt_test automatically because
> there's many of combinations of (m_cost,t_cost) values
> and we want to see the --test with the concrete values
> of t_cost and m_cost
It's not just auto tuning. Unless I misunderstand the problem, the very
function you need is reset(). For example like this:
- On reset(NULL), as in self-test, you set some fixed low LWS/GWS of eg.
32/128 and whatever mem_size is needed for test vectors' costs. Yes, you
will get an extra compile here, but that's faster than a self-test with
full LWS/GWS anyway.
- On reset(db), you parse the db and see what costs you actually need.
Then you release the temporary buffers/kernel, and auto-tune using the
costs that are actually needed (you can even auto-tune with the very
hashes loaded for cracking, which should be optimal).
BTW compiled kernels will be cached. For nvidia the driver caches it.
For AMD, we do.
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.
