Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 18 Oct 2012 22:21:11 +0530
From: Sayantan Datta <std2048@...il.com>
To: john-dev@...ts.openwall.com
Subject: Re: bitslice DES on GPU

On Thu, Oct 18, 2012 at 11:47 AM, Solar Designer <solar@...nwall.com> wrote:

> It would imply something other than bitslicing for K as well.  And the
> S-boxes would be represented differently, too.  But I think you should
> stop thinking in this direction.  I don't expect there's another useful
> representation inbetween bitslicing and straightforward table lookups.
>

The primary reason for thinking in direction is to decrease the  load on
registers and local memory so that there are more number of inflight
wavefront. Also decreasing the size of B[] to 16 ints would almost ensure
that it really stays in private register space. Right now I doubt the B[]
arrays are stored in register address space because each VGPR is only
256bit wide. However that depends entirely on how the VGPRs are used. For
SIMD execution I think it is more logical to assume that each VGPR is
loaded with data from 16 different kernels and not from only one kernel.
Still if the array is not in register space we could be loosing lots of
performance.  Also it could be possible to use 4 array of 16 ints to
represent the B[] array of 64 ints. But the indirect addersing using the 96
index array is causing problem.
       Since the 96 index array is almost constant the indexing could be
done prior to execution. However it might require some radical approach
like pre compiling the kernels manually.

Regards,
Sayantan

Content of type "text/html" skipped

Powered by blists - more mailing lists

Your e-mail address:

Powered by Openwall GNU/*/Linux - Powered by OpenVZ