[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20120401041622.GA3301@openwall.com>
Date: Sun, 1 Apr 2012 08:16:22 +0400
From: Solar Designer <solar@...nwall.com>
To: john-dev@...ts.openwall.com
Subject: Re: fast hashes on GPU
On Sat, Mar 31, 2012 at 09:18:54PM +0300, Milen Rangelov wrote:
> I think you would be very disappointed by the SHA512 speed on GPUs
> (especially AMD ones). it is not twice slower than SHA256, more like 10
> times slower. There are several reasons for this, mainly that there are no
> 64-bit bitwise rotation and bitselect, 64-bit arithmetics being slow
> emulated in software and slower, higher GPR pressure. On VLIW GPUs it's
> even worse because of the GPR utilization, the best speeds are utilized
> with 2-wide vectors and that does not provide enough independent operations
> to fill in all VLIW bundles, thus you get much lower ALUPacking as compared
> to sha256.
Yes, I expected that SHA-512 would be less efficient on AMD/ATI GPUs
compared to many other hash types on the same hardware. 10x slower than
SHA-256 is extreme, though. I thought/think that the difference should
be less.
> On NVidia, situation is somewhat better though.
Yes, that's my expectation, although it's largely due to other
("competing") hash types being less efficient there (no rotate and
bitselect anyway). I think the only major reason why SHA-512 may be
more than twice slower than SHA-256 on current Nvidia GPUs is the
increased register pressure. Right?
As you probably recall, we picked raw SHA-512 (and its salted variants)
for one of the first "fast" hashes to experiment with precisely because
it is on the slower side of the fast hashes and thus should fit in the
current formats interface better. For faster fast hashes, we'll need to
proceed with more invasive changes.
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.
