[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <49d431d76fb45765ad3e185d8a7cd72e@smtp.hushmail.com>
Date: Wed, 5 Dec 2012 23:12:05 +0100
From: magnum <john.magnum@...hmail.com>
To: john-dev@...ts.openwall.com
Subject: Re: self-test duration vs. GPU benchmarks
On 5 Dec, 2012, at 21:27 , Solar Designer <solar@...nwall.com> wrote:
> On Wed, Dec 05, 2012 at 01:40:40AM +0100, magnum wrote:
>> As core John development has come to a full halt I have now merged this
>> patch to unstable-jumbo instead of just to bleeding. We'll want it in
>> Jumbo-8 anyway.
>
> I'm not so sure about jumbo-8, but it appears that you've decided for
> me, and I have no grounds to object - it is my fault that I haven't
> released a new core version yet. I am sorry about that. I do intend to
> resume core John development.
I'm perfectly fine with going directly towards 1.8-jumbo-1, if that is what you mean. In fact I would prefer that. I assumed you'd want a jumbo-8 given the huge difference between J7 and unstable. OTOH we never manage to "feature freeze" the tree anyway - it always makes people commit more :-)
>> I would like to add a new format flag in Jumbo: FMT_GPU. With that in
>> place, we can omit GPU formats from the --test [all] case (with a
>> comment printed) right now, and we could also handle self-tests somewhat
>> differently from CPU formats - like testing a good number of hashes in
>> one call to crypt_all() instead of trying one at a time in a large
>> number of long-duration calls.
>
> OK, although I think the revision to self-test should eventually be made
> for all formats, and done() should be implemented for the GPU formats so
> that they can be included in --test.
Maybe you are right, but it depends a lot on the below. Also, I have a vague feeling we could want to do GPU tests a bit differently than CPU tests anyway.
> Aren't you merging the patch that
> adds done() now? Anyhow, you're the one to decide on this, as someone
> more active at JtR development than I am. ;-)
I was going to merge them long ago, and in hindsight I'm really glad I never did. I really want those patches but merging them [to bleeding but not unstable] will lead to a lot of trouble until next core is actually released. And that could be a year from now from all I know (no offense!). Keeping two (let alone three as we had for a while) git trees apart is a constant source of confusion and extra work. I need to back-port and forward-port stuff that people commit to different (wrong) branches. It was much worse when we had jumbo-6-fixes. Currently it's just the v10 format struct and that's OK. If I merge the done/reset/etc patches now, it would get out of hands.
So the best solution for me would be to freeze (and just forget) the current unstable-jumbo branch right away and continue work in bleeding-jumbo only. This conclusion was not clear to me until right now, as I wrote this %-)
magnum
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.
