[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CA+TsHUDp_FTiKEbfQoeXTKB3P6VV1nvgPBB9QMVfnGm=W9MvoA@mail.gmail.com>
Date: Tue, 3 Apr 2012 19:12:31 +0530
From: SAYANTAN DATTA <std2048@...il.com>
To: john-dev@...ts.openwall.com
Subject: Re: GSoC Project proposal:JtR GPU for Slow hashes
Hi Alexander,
>
> Fixing this is something you could work on, yes. If there's any
>> performance impact from such fixes (for newer GPUs that don't need the
>> fixes), then both versions of the code should be present (but without
>> duplication of source code shared between the versions).
>>
>
I think only the kernels would require two different versions.
>
> Several of them build upon PBKDF2 with
>
>> SHA-1 (and for Mac OS X 10.8 apparently we'll need PBKDF2 with SHA-512,
>> but I haven't looked into that yet), so that's one thing to have and to
>> optimize really well.
>>
>
As of now I will modify the PBKDF2 step and optimize it as much as I can.
But later ,I'm considering reimplementation of the PBKDF2 step from scratch
keeping in mind all possible optimizations from the beginning. On the
newer GPUs I will have much more flexiblity than current one.
> Similarly, the existing OpenCL and/or CUDA code needs to be optimized
>> further. Lukas said that this is what he intends to apply for under
>> GSoC, but that does not prevent you from offering to work on it as well.
>>
>
>
That would be great as we could learn a lot from each other.
> Thank you for suggesting this. I think it'd be best if you test your
>> code on multiple GPUs as you develop - not postpone porting to another
>> GPU family as a separate task. It'd be nice if you could get more than
>> two GPUs - not just 4000 series vs. newer, but also Nvidia. I realize
>> that buying lots of GPUs is costly, though.
>>
>
I could only buy one GPU but you are welcome to suggest the brand. (As a
Radeon fanboy I am a little biased toward it.:) )
> Multi-GPU support within one instance of JtR would be very nice to have.
>> There are two major approaches to this, I think: high-level (similar to
>> what we have with MPI now) vs. per-format (similar to our current OpenMP
>> stuff). It might be best to support both (they have their pros and cons).
>> This deserves its own discussion thread, though.
>>
>
I'll discuss this topic for later on a seperate thread.
Regards,
Sayantan
>
>
>
>
Content of type "text/html" skipped
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.
