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.