[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20130923193231.GA6276@openwall.com>
Date: Mon, 23 Sep 2013 23:32:31 +0400
From: Solar Designer <solar@...nwall.com>
To: john-dev@...ts.openwall.com
Subject: Re: Rafael's weekly report #14
Rafael,
Please don't forget to provide your final mandatory weekly report today.
On Mon, Sep 23, 2013 at 01:00:41PM +0200, Rafael Waldo Delgado Doblas wrote:
> 2013/9/21 Solar Designer <solar@...nwall.com>
> > 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?
>
> Mmm, I checked it and it worked fine to me. Are you compiling with the flag
> EPIPHANY_DEBUG?
I think not. I compiled a clean "git clone" tree with no changes. What
performance does it give you?
> > 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)?
>
> Yes it is. As GSoC it's about to finish I commited a working version but I
> have another one with macros but still buggy.
Where is this other version? May I take a look? You attached some
version to this message (that I am replying to), but it does not use
macros and it is unclear what you attached it for.
Regarding using autotools to build the Epiphany code from Makefile:
> > 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.
>
> It's ok, after I checked autotools doc, I couldn't see how to do it then
> maybe it's not possible.
Actually, I think it's possible and most likely trivial. It's just that
I am not familiar with autotools. I guess I could figure this out, but
so could you.
Have you tried simply including the right make rules in Makefile.am,
don't they propagate to the final Makefile verbatim?
Like I said, this is unimportant at this time, though.
> > 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?
>
> Mmm, I have added this. Doesn't it worked? I will check it ASAP.
>
> strcpy(fullpath, cgminer_path);
> strcat(fullpath, "epiphany-scrypt.srec");
> if (e_load_group(fullpath, dev, 0, 0, rows, cols, E_FALSE) == E_ERR) {
> applog(LOG_ERR, "Error: Could not load epiphany-scrypt.srec on Epiphany.");
> applog(LOG_ERR, " Is epiphany-scrypt.srec in cgminer directory?.");
> return false;
> }
I did not know/notice that you added this. I hope it works, but you do
need to test it and report whether it does work.
> > > > 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?
>
> Hello, I have implemented the interleaving of 2 and I copy get_hash* and
> binary_hash* functions from lotus5 (changing crypt_key[] array size). I
> have doubts about get_hash* and binary_hash* functions why are there 7 and
> what do they do?.
Oh, I thought you'd merely provide a status update in response to this
message, leaving the actual discussion to the proper thread ("reply" to
the message "dominosec optimization".
Anyway, regarding the 7 get_hash* and binary_hash* functions, they're
for 7 different hash table sizes, where a given size is used depending
on the number of hashes loaded for cracking (for a given salt, if
applicable). See the comments in formats.h, inside the definition of
"struct fmt_methods". Also see PASSWORD_HASH_* in params.h, and the
corresponding arrays in params.c. (I thought you knew this already,
from your work on an scrypt format for JtR.)
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.
