Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 23 Jul 2015 13:07:57 +0200
From: Agnieszka Bielec <bielecagnieszka8@...il.com>
To: john-dev@...ts.openwall.com
Subject: Re: PHC: my yescrypt and lyra2 benchmarks

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:
>> 2015-07-22 17:01 GMT+02:00 Solar Designer <solar@...nwall.com>:
>> >> Lyra2
>> >>
>> >> well - 4264
>> >> GeForce GTX 960M - 522
>> >> AMD Radeon HD 7900 Series - 3385
>> >> GeForce GTX TITAN - 1735
>> >>
>> >> yescrypt
>> >>
>> >> well - 4688
>> >> GeForce GTX 960M - 206
>> >> AMD Radeon HD 7900 Series - 319
>> >> GeForce GTX TITAN - 326
>> >
>> > OK.  These are using the same memory (de)allocation approach, out of the
>> > loop, correct?  I mean on CPU.
>>
>> 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()

>> 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

Powered by blists - more mailing lists

Your e-mail address:

Powered by Openwall GNU/*/Linux - Powered by OpenVZ