Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20150723014701.GA2172@openwall.com>
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.