Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 22 Aug 2013 14:08:11 +0400
From: Solar Designer <solar@...nwall.com>
To: john-dev@...ts.openwall.com
Subject: Re: Parallella: Litecoin mining

Rafael,

How is your SCRATCHBUF_SIZE calculated?  You have:

// ((1023 / TMTO_RATIO) + 1) * 128

#define SCRATCHBUF_SIZE 22464
#define TMTO_RATIO 6 // Must be > 0

However, when I substitute 6 into the formula in the comment, I get only
21888, not 22464.  Is the 22464 number right, and why?  Can you please
edit this file so that SCRATCHBUF_SIZE uses a formula rather than a
constant on the #define line?  For example:

#define TMTO_RATIO 6
#define SCRATCHBUF_SIZE (((1023 / TMTO_RATIO) + 1) * 128)

(if that formula is right).  Any decent optimizing compiler will compute
this at compile time anyway.

The code in scrypt_1024_1_1_256_sp() adds 64-byte alignment, so may
waste up to 63 bytes.  If you do implement any alignment like this, then
you need to account for it (worse case) in SCRATCHBUF_SIZE.  However,
please note that, unlike systems with cache, Epiphany does not benefit
from larger than 8-byte alignment (and it only benefits from 8-byte
alignment if your code manages to use LDRD/STRD instructions, otherwise
it only needs 4-byte alignment).  Thus, I suggest that you drop the line
that implements alignment manually and don't include it in
SCRATCHBUF_SIZE either, but instead define scratchpad like this:

	char scratchpad[SCRATCHBUF_SIZE] __attribute__ ((aligned (8)));

then you can do simply:

	V = (uint32_t *)scratchpad;

... or arguably it may be cleaner to use:

	uint32_t scratchpad[SCRATCHBUF_SIZE / 4] __attribute__ ((aligned (8)));

and then:

	V = scratchpad;

"__attribute__ ((aligned (8)))" is gcc-specific, but we assume e-gcc for
the Epiphany code anyway.  (If we were writing more portable code, we
could use a "union" with a "long long" or a "double" inside it to
achieve 8-byte alignment.)

Alexander

Powered by blists - more mailing lists

Your e-mail address:

Powered by Openwall GNU/*/Linux - Powered by OpenVZ