Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20130822211813.GA29672@openwall.com>
Date: Fri, 23 Aug 2013 01:18:13 +0400
From: Solar Designer <solar@...nwall.com>
To: john-dev@...ts.openwall.com
Subject: Re: Parallella: Litecoin mining

Rafael,

On Thu, Aug 22, 2013 at 10:06:39PM +0100, Rafael Waldo Delgado Doblas wrote:
> 2013/8/22 Solar Designer <solar@...nwall.com>
> 
> > Your epiphany-scrypt.c currently contains the entire scrypt (albeit
> > specialized to the parameter values needed for Litecoin mining).
> >
> > This means that it contains not only Salsa20/8, BlockMix, and SMix, but
> > also SHA-256 and PBKDF2.  Given that in scrypt almost all processing
> > time is spent in SMix, we should move SHA-256 and PBKDF2 to host.  Leave
> > only SMix on Epiphany.  This will free up some local memory, which
> > should enable us to decrease the TMTO factor.
> >
> > Ideally, the two PBKDF2 computations (before and after SMix) that we'll
> > perform on host should overlap with SMix computation on Epiphany.
> 
> Ok I will work on it now.

I thought of this some more since I posted the above.  When we're using
just one core on the host, it will have to compute those SHA-256's for
all Epiphany cores sequentially.  For 64-core Epiphany, this means 128
SHA-256's to compute.  This should take less time than it takes Epiphany
cores to compute their instances of SMix, yet 128x SHA-256 is a
significant delay.  So 100% overlap with SMix computation is a must if
you do move the PBKDF2-HMAC-SHA-256 to host.  This implies that you need
to start computing the next set of instances of scrypt (their initial
PBKDF2's) before SMix of the current set of instances complete.

We may also experiment with optimizing SHA-256 for size while keeping it
on Epiphany side.  Maybe we'll be able to achieve a TMTO factor of 4.5
(leaving us 3 KB for all components of scrypt) even in this way, even
though right now you're not anywhere close to that.  I think making
SHA-256 about 3x smaller than its current fully-unrolled implementation
in epiphany-scrypt.c is might be realistic.

You may experiment with both approaches (separately) - move to host or
optimize for size (by which I mean source code level optimizations, not
compiler settings).

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.