[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20120811220952.GA1725@openwall.com>
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.
