Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 9 Sep 2013 08:59:39 +0200
From: Rafael Waldo Delgado Doblas <lord.rafa@...il.com>
To: john-dev@...ts.openwall.com
Subject: Re: Parallella: Litecoin mining

Hello Alexander,

My apologies because there wasn't daily reports this weekend, I had to move
to a new place yesterday. This Friday a ran a couple of test using my
computer and finally I find why there was only rejected share and on
Saturday I fix it. Also I change the run script now to run it, you need run
with sudo -E

Regards,
RafaeƱ


2013/9/8 Solar Designer <solar@...nwall.com>

> 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
>

Content of type "text/html" skipped

Powered by blists - more mailing lists

Your e-mail address:

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