Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 6 Feb 2006 05:27:56 +0300
From: Solar Designer <>
Subject: Re:  GPU acceleration?

On Mon, Feb 06, 2006 at 01:25:35AM +0000, Radim Horak wrote:
> maybe this is totally crazy idea, but I'm quite sober, so let me start with this 
> citation that summarizes my inspiration:
> "The SM3.0 GPUs have become general and powerful enough to perform a broader 
> range of computations ??? beyond the role of pure graphical shading for which they 
> were initially used."

This used to be a crazy idea when it was discussed some years ago - but
it is quite reasonable nowadays.  In fact, this question was also raised
in an interview I gave on John the Ripper 1.7 recently (to be published
soon).  Some other relevant links are:

No, I have not looked into this yet, and I am not planning to any time
soon (I simply have no time for that).  My first impression, however, is
that GPUs are unlikely to be very efficient at bitwise operations -
which is what we need for John.  They likely offer more of a benefit
over general-purpose CPUs at floating-point operations.  On the other
hand, modern general-purpose CPUs can do floating-point multiplies at a
rate of one or several per cycle (with a latency of multiple cycles),
yet GPUs are reported to offer even better performance - so I could be
wrong about my expectations for their performance at bitwise ops.

I'd appreciate it if anyone could provide more specific information on
the performance of current GPUs at bitwise ops.  Just how much
parallelism is available, exactly?  The clock rates appear to be fairly
low compared to general-purpose CPUs, so that will have to be
compensated for by much longer vectors (1024+ bits?) for the use of GPUs
for John to be feasible.

Radim - there was a discussion on hardware accelerators for John on this
mailing list before I think you started to monitor it.  You could want
to review it:

The expected conclusion was that FPGAs are the way to go, this only
needs to be implemented.

Alexander Peslyak <solar at>
GPG key ID: B35D3598  fp: 6429 0D7E F130 C13E C929  6447 73C3 A290 B35D 3598 - bringing security into open computing environments

Was I helpful?  Please give your feedback here:

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.