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

Hi Rafael,

On Thu, Aug 29, 2013 at 12:11:56AM +0100, Rafael Waldo Delgado Doblas wrote:
> The problem was in RNDr macro. The loop that call the RNDr macro only cares
> about the first line of RND (macro inside of RNDr), because a missing keys
> { }. After I fixed this small bug the performance is ~1.3K/h

Great.  I am happy that you're finally making progress again.

> (also I have
> replaced the memcpy by a own made function because it adds 0.2K/h,
> increasing 8 bytes).

Does this mean that replacing memcpy() improved the overall speed by as
much as 15% or so?  If so, this suggests that the code wastes too much
time copying data, and needs to be revised at higher level (than memcpy()
itself), in addition to optimizing memcpy().

Also, I just took a look at your currently committed code - your
memcpy() replacement, at least at source code level, copies data byte by
byte.  This is very slow, unless the compiler optimizes this into 32-bit
or 64-bit loads and stores somehow.  I doubt that replacing memcpy()
with this implementation of blkcpy() provided any speedup (but I could
be wrong - weird things happen).

Ideally, your blkcpy() should be a partially unrolled loop with LDRD and
STRD instructions in it, and all of the data needs to be 8 byte aligned.

> I'm checking the bug in the host code

Do you mean the occasional segfault?  How are you debugging it, exactly?
(I asked you this question a few days ago, but you did not answer.)

> and I will move to asm ASAP

OK, although there's more we can do at C level as well.

What portions of code will you be rewriting in asm?  Are you starting
with inline asm or with a separate assembly source file?

> the optimistic performance would be 1.7K/h.

It should be much better than that.

Alexander

Powered by blists - more mailing lists

Your e-mail address:

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