[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20150705134100.GB28792@openwall.com>
Date: Sun, 5 Jul 2015 16:41:00 +0300
From: Solar Designer <solar@...nwall.com>
To: john-dev@...ts.openwall.com
Subject: Re: PHC: Lyra2 on GPU
On Sun, Jul 05, 2015 at 01:27:51PM +0200, Agnieszka Bielec wrote:
> 2015-07-05 9:39 GMT+02:00 Solar Designer <solar@...nwall.com>:
> > On Sun, Jul 05, 2015 at 09:05:19AM +0300, Solar Designer wrote:
> >> Is the memory (de)allocation overhead kept out of the loop already?
> >> I previously suggested that you reuse yescrypt's yescrypt-platform.c:
> >> *_region() functions for this, so that we use the same memory allocation
> >> mechanism for all PHC finalists.
> >
> > Just to make it clear: this is important and high priority, for all of
> > your PHC finalist formats.
> >
> > I feel I have to state it this way since you appear to have been
> > ignoring/postponing this task for a long while.
>
> it's out of the loop but not like in yescrypt
> it's in set_salt and only when costs are different than previously
> memory is allocated again, this is not effective only when we are
> cracking passwords with different costs at once. in my test first and
> second hash always have the same costs
OK, that's better than I expected, but not good enough: we need to unify
the approach to memory allocation across the PHC finalists, to ensure
our benchmark results are not affected by possible differences in this
area (since there would be no differences).
It's not just the performance overhead of the (de)allocation operation.
It's also what kind of allocation is returned - such as whether huge
pages are used or not.
So I suggest that we unify them all to use yescrypt-platform.c:
*_region() functions, and then we'll have this code in just one place,
including e.g. its huge pages threshold.
Also, reallocating on set_salt() will have unnecessary performance cost
when cracking hashes with different cost settings. It's better to let
the allocation grow or be replaced with the largest one needed in a
given run, and then just use that all the time - even for salts where
only a portion of the allocated region would be written to. The
*_region() functions are designed to be used like that.
Maybe you'll approach switching your already implemented PHC finalist
formats to use of yescrypt's *_region() once you implement a yescrypt
format?
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.
