[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20130920231508.GC19429@openwall.com>
Date: Sat, 21 Sep 2013 03:15:08 +0400
From: Solar Designer <solar@...nwall.com>
To: john-dev@...ts.openwall.com
Subject: Re: Rafael's weekly report #14
Rafael,
On Wed, Sep 18, 2013 at 10:28:16PM +0200, Rafael Waldo Delgado Doblas wrote:
> As I couldn't debug the asm code I cleaned a little bit the code and I
> added a user friendly way to compile the code.
I took a look at your committed code as of a few hours ago, and tried
building and running it (the C code only for now, as I take it the asm
is in a non-working state anyway). Here are some observations, in
arbitrary order:
1. EPIPHANY-README is the right kind of documentation, thank you!
A minor correction: s/SUDO -E/sudo -E/ as otherwise it is unclear that
you're referring to the uppercase "-E". Also, maybe wrap the lines at
79 chars, as some other documentation files in cgminer appear to do
(albeit not consistently).
2. I notice that you integrated Epiphany code build into autogen.sh.
Ideally, it'd be invoked from the Makefile, but what you did is OK for
now.
3. Somehow the performance is a lot worse than it used to be. With a
default build, I got only around 300 h/s; we used to have ~1300 h/s.
What is causing this slowdown (some compiler flags set for debugging?
some code change?) and can you please correct it?
4. I think epiphany-salsa208.S could nicely stay with the underscore
between 20 and 8, or did this somehow not work?
5. You're still not using any macros in the .S file. Do you have some
non-committed version that does use macros (but is buggy, as you
mentioned)? Is the committed asm code supposed to be in a working
state, then (but is just slow)?
6. Your reintroduced C code for salsa20_8() is no longer indented.
Please correct that.
> Today I'm going to debug the asm
Any luck with that? It's been another 3 days. From the amount of time
this is supposedly taking you, it feels like you're approaching this asm
problem in some weird way. When I asked you what the purpose of your
non-macro-using asm code was, you said that it was a starting point for
further work on the asm code - if so, you should be able to convert it
to use of macros step-by-step, with testing after every step, and then
it'd be fairly easy for you to spot the occasional errors that you'll be
making (not a lot of code changes to review for each error).
Personally, I think you'd do it even quicker by starting with extensive
use of macros instead of the fully expanded version you wrote, but since
you already have it anyway, you may as well use it to simplify your work
on the macros.
After you're using macros to the maximum reasonable extent, sacrificing
performance even, it should similarly not be too difficult for you to
start moving to larger macros step-by-step, only as needed for better
instruction scheduling. You'd similarly test after making each change,
so that you don't have a lot of changes to review for any errors
whenever the changed code fails test.
Can you describe your approach?
> El 17/09/2013 02:31, "Rafael Waldo Delgado Doblas" <lord.rafa@...il.com>
> escribi?:
> > Problems:
> > 1. I couldn't find a way to compile cgminer with a-gcc and epiphany-scypt
> > with e-gcc using autotools and only one call to autogen.sh and make. I will
> > write a bash script to do it but would be nicer if someone can help me with
> > this.
I'm sorry we didn't get around to helping you on this sub-task.
I think it could be as simple as having some make rules pre-written in
Makefile.am, but I am not sure. I am not familiar with autotools.
BTW, have you fixed your host side C code not to segfault when the
Epiphany code hasn't been compiled? Can you make it print a reasonable
error message, please?
> > 2. Implemented macros and instruction schedule in epiphany asm but I have
> > some bugs to fix.
When did you realize you had bugs to fix? Do you have a code version
with macros, but without instruction scheduling - as I had requested?
(I asked that you commit this one first, before instruction scheduling,
and only then add instruction scheduling with a separate commit.)
> > Priorities:
> > 1. Debug asm. Hopefully tomorrow will be fixed.
Was it?
> > 2. Implement a end user friendly script to compile cgminer.
OK. Mostly done.
> > 3. Move to the new task related with jumbo.
Actually, I thought that this new task would be more of a "filler" for
when you're "idle" waiting for my feedback on your current main task, so
you would not exactly "move" to it after finishing the current task, but
rather you'd work on both.
Anyhow, what's the current status on it?
Thanks,
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.
