Date: Sun, 12 Aug 2012 02:09:52 +0400 From: Solar Designer <solar@...nwall.com> To: john-dev@...ts.openwall.com Subject: Re: DES_BS_ASM in DES_bs_b.c Sayantan - On Sun, Aug 12, 2012 at 02:05:06AM +0530, Sayantan Datta wrote: > I thinking to port only the plain non-vectorized and non-sse2/mmx code path > to opencl. Is it all right or do I need to look at the other code paths too? A way to support GPUs would be via having a very high DES_BS_DEPTH. On the CPU side, this will probably amount to let's say virtual vectors of a sufficient number of ARCH_WORD sized elements. Of course, with LM hashes we'll immediately bump into the CPU/GPU transfers bottleneck, as well as into the password generation bottleneck, but that's expected and would need to be dealt with separately (another project or milestone). With DES-based crypt(3) hashes, this might actually work reasonably (should bump into these two bottlenecks as well, yet might outperform CPU). You're correct that you do not need the CPU-hardware-supported vectors in your GPU-interfacing code. If there are performance-critical places where wider than ARCH_WORD operations would speed things up, this suggests that more code should be moved to GPU. 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.