[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20130726230303.GA24959@openwall.com>
Date: Sat, 27 Jul 2013 03:03:04 +0400
From: Solar Designer <solar@...nwall.com>
To: john-dev@...ts.openwall.com
Subject: Re: Parallella: Litecoin mining
Rafael -
On Fri, Jul 26, 2013 at 09:57:10PM +0100, Rafael Waldo Delgado Doblas wrote:
> The Alexander's escrypt-tmto1 needs ~64K plus the executable binary image
> size then even with this TMTO ratio is not enough to work with Parallella.
Please take a closer look at escrypt-tmto1. Its TMTO ratio is fully
configurable. In fact, tests.c in the tarball that I sent you has
exploit_tmto set to 100 - so that's the TMTO ratio in effect when you
build and run the tests as-is.
This posting by me gives some numbers on scrypt's memory needs and
computation time with different TMTO ratios:
http://www.openwall.com/lists/crypt-dev/2013/03/21/1
As you can see, with a ratio of 4 we reduce the memory usage by V from
128 KB to 32 KB, whereas the amount of computation increases by less
than a factor of 2 (from 32768 to ~57348). Since we probably can't
afford 32 KB for V (we also need to leave room for code, stack, B, and
XY), we'll need to use a ratio of 5 (which would result in an increase
in the amount of computation very close to 2) or slightly more. Note
that at a ratio of 8 (where we need only 16 KB for V), the amount of
computation is increased by less than a factor of 3 (from 32768 to
~90500). I did not include ratios inbetween 4 and 8 in that posting,
but they can be implemented and they will provide numbers somewhere
inbetween. (However, note that you must avoid integer division; I did
not bother avoiding it in my experimental code, but you must.)
> I was thinking in raise the CPU use in escrypt-tmto1
Right.
> but is there a better way to get Scrypt on Parallella without raise cpu use?
No. As far as I am aware, other ways are worse.
> Do I losse something?
This is a tradeoff. We just need to do it optimally.
> BTW: The only function that we need to port to Epiphany is:
>
> scrypt_1024_1_1_256_sp(data, scratchbuf, ostate);
Initially, yes, however note that at a speed of up to ~5 kh/s on 16-core
and ~20 kh/s on 20-core, the external memory access and communication
delays may be slowing it down, so eventually you could want to implement
async processing (two sets of inputs/outputs) or move more code to
Epiphany.
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.
