[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 23 Jul 2015 03:47:01 +0200
From: Solar Designer <solar@...nwall.com>
To: john-dev@...ts.openwall.com
Subject: Re: PHC: my yescrypt and lyra2 benchmarks
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?
> 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.
> btw I reverted back my changes in alloc_region()
Great.
Alexander
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.
