[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Fri, 24 Jul 2015 00:01:33 +0200
From: Agnieszka Bielec <bielecagnieszka8@...il.com>
To: john-dev@...ts.openwall.com
Subject: Re: PHC: my yescrypt and lyra2 benchmarks
2015-07-23 18:35 GMT+02:00 Solar Designer <solar@...nwall.com>:
> On Thu, Jul 23, 2015 at 01:07:57PM +0200, Agnieszka Bielec wrote:
>> 2015-07-23 3:47 GMT+02:00 Solar Designer <solar@...nwall.com>:
>> > On Wed, Jul 22, 2015 at 09:40:02PM +0200, Agnieszka Bielec wrote:
>> >> yes, but in Lyra2 I'm allocting small parts in malloc and big parts in
>> >> *_region before crypt_all
>> >
>> > In other words, you do still have some memory (de)allocation overhead in
>> > the cracking loop for Lyra2? That's not great. Even if the overhead is
>> > actually negligible (since those allocations are small), we wouldn't
>> > know that reliably until we've tried eliminating it. Please do.
>> >
>> > ... or did I misunderstand, and those small malloc()s are invoked
>> > outside of the cracking loop? Where?
>>
>> outside in set_salt()
>
> This isn't entirely outside. With many hashes with different salts
> loaded for cracking at once, set_salt() will be invoked once per each
> (at most) max_keys_per_crypt candidate passwords.
but I have
if(prev_saved_salt.m_cost==saved_salt.m_cost &&
prev_saved_salt.nThreads==saved_salt.nThreads &&
prev_saved_salt.nCols==saved_salt.nCols)
return;
I was thinking about only choose the biggest values but lyra2 has many
parameters and many arrays and if I had wanted to choose the biggest
all arrays here there would exists the situation that we don't have
enough memory and we have enough memory using this code above.
anyway for the same costs (and they are the same here) this isn't bad
>
>> >> in yescrypt I'm allocating in crypt_all() but only at first call
>> >> crypt_all(), I didn't changed function yescrypt_kdf() and
>> >> yescrypt_kdf_body(),
>> >
>> > Sounds fine.
>> >
>> >> can this be like here?
>> >
>> > I don't understand your question.
>>
>> I'm asking if it's ok to have allocating at first call crypt_all, above
>
> Yes, that's OK. The only overhead is then a conditional branch, which
> is clearly negligible compared to the time spent in these slow hashes.
even there is no overhead in this situation (--test is passed and
--skip-self-test is not passed)
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.
