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

Rafael,

I took a look at epiphany-salsa20_8.S as currently committed.  What's
the purpose of the approach you've taken so far - writing asm code
without use of macros, and without an attempt at instruction scheduling
either (or so it looks)?

I suggest that you start by using macros as much as you can (commit this
first), and only then expand some of them manually if you absolutely
have to in order to achieve decent instruction scheduling.  I guess that
you'll find that rather than avoid use of macros, you'd need to use
different macros - such as a macro doing several things at once (just
enough for proper instruction scheduling inside it), and you'll be able
to invoke that macro several times as appropriate.

Please take a look at Katja's parallella_e_bcrypt.S.

Also, please keep the pure C version of the code around, and please
make it possible and easy to build cgminer with either code version
(pure C or C+asm).  This is needed e.g. to experiment with algorithm
level changes, which would be more time-consuming to have to make to the
asm version right away.  It is also needed to troubleshoot problems
(e.g. "is this problem we're having possibly with the asm code being
incompatible with the new platform? let's try disabling asm to find out" -
for whatever problems we or the users might run into at a later time).

Regarding the likely/unlikely stuff in epiphany-scrypt.c - did it result
in any speedup, in your testing?  It might, if it results in a reduction
in total number of taken branches.  (On Epiphany, any taken branch costs
3 cycles.  This applies to unconditional branches, too.)

Alexander

Powered by blists - more mailing lists

Your e-mail address:

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