Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
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.