Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20130810131031.GA8291@openwall.com>
Date: Sat, 10 Aug 2013 17:10:31 +0400
From: Solar Designer <solar@...nwall.com>
To: john-dev@...ts.openwall.com
Subject: Re: Parallella: Litecoin mining

Rafael,

On Sat, Aug 10, 2013 at 03:14:26AM +0100, Rafael Waldo Delgado Doblas wrote:
> Indeed, but finally I could decrease the TMTO up to 6 and now the
> performance is ~1.150Kh/s.

This is good news, although the target performance is much higher - I'd
guesstimate 3 kh/s with pure C and 4-5 kh/s with asm code.  (We had a
smaller difference between pure C and asm for Katja's bcrypt code - with
best asm speed being about 20% higher than best C speed - but for scrypt
I'd expect a bigger difference due to potential use of IMADD for bit
rotates, and due to Salsa20 containing relatively more ADDs than XORs,
as compared to Blowfish.)

> TMTO 5 fails, I need to check why.

OK.  At a later time, you could even try 4.5, if you make your code
really compact.  (Of course, supporting a TMTO factor that is not a
whole number requires slightly different code.)

I think at this time your priority should be to find out why you're not
getting more than 1.15 kh/s at TMTO factor 6.  You could get something
like 2+ kh/s with pure C code with it, with more optimal code (this is
just my gut feeling, though).

Is the code based off scrypt's -ref or -nosse?  Anyhow, even -nosse
performed a lot of unnecessary data copying.  This is something I
optimized in escrypt, but only in -sse code.  If the problem is indeed
still present in the code you're using, you could compare escrypt's
crypto_scrypt-sse.c against the original in scrypt-1.1.6.tgz and
implement similar optimizations (I mean removing blkxor and blkcpy) for
whatever code revision you have.

> size for TMTO 5 SCRATCHBUF_SIZE 26828 is
>    text    data     bss     dec     hex filename
>    7264    2584       8    9856    2680 epiphany-scrypt.elf
> 
> size for TMTO 6 SCRATCHBUF_SIZE 22464 is
>    text    data     bss     dec     hex filename
>    7264    2584       8    9856    2680 epiphany-scrypt.elf
> 
> size for TMTO 100 SCRATCHBUF_SIZE 1952 is
>    text    data     bss     dec     hex filename
>    7192    2584       8    9784    2638 epiphany-scrypt.elf
> 
> Is this a normal output?

It looks reasonable to me, except that I did not expect you'd have this
much pre-initialized data (2.5 KB).  What is it?

> Why the only information is about text, data and bss sections?.

What else did you expect to see there?  Your scratch space that you use
for scrypt's V?  How do you allocate it?

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.