Re: [PATCH 0/7] block-sha1: improved SHA1 hashing

From: Linus Torvalds <torvalds@linux-foundation.org>
Date: Aug 6, 2009, 23:42 UTC
Message-ID: <alpine.LFD.2.01.0908061625300.3390@localhost.localdomain>
In-Reply-To: <4A7B64F1.2000309@gmail.com>

On Fri, 7 Aug 2009, Artur Skawina wrote:

> 
> Actually that's even more of a reason to make sure the code doesn't suck :)
> The difference on less perverse cpus will usually be small, but on P4 it
> can be huge.

No. First off, the things you have to do on P4 are just insane. See the email I just sent out asking you to test whether two 1-bit rotates might be faster than 1 2-bit rotate.

So optimizing for P4 is often the wrong thing.

Secondly, P4's are going away. You may have one, but they are getting rare. So optimizing for them is a losing proposition in the long run.

> A few years back I found my old ip checksum microbenchmark, and when I ran
> it on a P4 (prescott iirc) i didn't believe my eyes. The straightforward 
> 32-bit C implementation was running circles around the in-kernel one...
> And a few tweaks to the assembler version got me another ~100% speedup.[1]

Yeah, not very surprising. The P4 is very good at the simplest possible kind of code that does _nothing_ fancy.

But then it completely chokes on some code. I mean _totally_. It slows down by a huge amount if there is anything but the most trivial kinds of instructions. And by "trivial", I mean _really_ trivial. Shifts (as in SHA1), but iirc also things like "adc" (add with carry) etc.

So it's not hard to write code that works well on other uarchs, and then totally blow up on P4. I think it doesn't rename the flags at all, so any flag dependency (carry being the most common one) will stall things horrible.

There's also a very subtle store forwarding failure thing (and a lot of other events) that causes a nasty micro-architectural replay trap, and again you go from "running like a bat out of hell" to "slower than a i486 at a tenth the frequency".

Really. It's disgusting. Perfectly fine code can run really slowly on the P4 just because it hits some random internal micro-architectural flaw. And there's a _lot_ of those "glass jaw" issues.

The best way to avoid them is to use _only_ simple ALU instructions (add, sub, and/or/not), and to be _very_ careful with loads and stores.

		Linus