Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CA+TsHUC9oRboq2ynnQUjZsUt4vCQVyA4Bxisc7q6jgUT03VGLQ@mail.gmail.com>
Date: Sat, 22 Sep 2012 10:58:50 +0530
From: Sayantan Datta <std2048@...il.com>
To: john-dev@...ts.openwall.com
Subject: Re: bitslice DES on GPU

On Sat, Sep 22, 2012 at 10:28 AM, Solar Designer <solar@...nwall.com> wrote:

> Is the 78 obtained as 2*39, where the 39 is my 39M figure for "overhead
> speed" of your previous code revision?  If so, if the overhead actually
> doubled, you'd need to halve its "speed" figure.  So you'd use 19.5 in
> this equation, not 78.  But your assumption that the overhead has
> doubled is probably wrong anyway, as I tried to explain above.  If the
> overhead did in fact double, you'd obtain total speed no better than 19.5.
>

I gave it a detailed thought to your calculations. In fact doubling the
work items shouldn't affect the speeds anyway. for example:

H c/s = W/(O+C) : where W = no. of work items
                                      O = time spent on overhead.
                                      C  = time spent on actual
(non-overhead) hashing.
                                      H = actual real world speed.
So if W is doubled , O and C should get doubled automatically as both O and
C are proportional to W.

What happened is that I manged to reduce the overhead (using different
code) while slowing down the actual hashing(using different kernel).

Anyway  I managed to improve the non-overhead speeds to 59M c/s using
nvidia s-boxes and putting B[] in private register space on 7970. AMD
s-boxes aren't working .

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.