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.