Re: x86 SHA1: Faster than OpenSSL

From: Linus Torvalds <torvalds@linux-foundation.org>
Date: Aug 6, 2009, 04:50 UTC
Message-ID: <alpine.LFD.2.01.0908052137400.3390@localhost.localdomain>
In-Reply-To: <4A7A5BE2.5070401@gmail.com>

On Thu, 6 Aug 2009, Artur Skawina wrote:

Show 9 quoted lines

> 
> #             TIME[s] SPEED[MB/s]
> rfc3174         1.357       44.99
> rfc3174         1.352       45.13
> mozilla         1.509       40.44
> mozillaas       1.133       53.87
> linus          0.5818       104.9
> 
> so it's more than twice as fast as the mozilla implementation.

So that's some general SHA1 benchmark you have?

I hope it tests correctness too.

Although I can't imagine it being wrong - I've made mistakes (oh, yes, many mistakes) when trying to convert the code to something efficient, and even the smallest mistake results in 'git fsck' immediately complaining about every single object.

But still. I literally haven't tested it any other way (well, the git test-suite ends up doing a fair amount of testing too, and I _have_ run that).

As to my atom testing: my poor little atom is a sad little thing, and it's almost painful to benchmark that thing. But it's worth it to look at how the 32-bit code compares to the openssl asm code too:

 - BLK_SHA1:

	real	2m27.160s
	user	2m23.651s
	sys	0m2.392s

 - OpenSSL:

	real	2m12.580s
	user	2m9.998s
	sys	0m1.811s

 - Mozilla-SHA1:

	real	3m21.836s
	user	3m18.369s
	sys	0m2.862s

As expected, the hand-tuned assembly does better (and by a bigger margin). Probably partly because scheduling is important when in-order, and partly because gcc will have a harder time with the small register set.

But it's still a big improvement over mozilla one.

(This is, as always, 'git fsck --full'. It spends about 50% on that SHA1 calculation, so the SHA1 speedup is larger than you see from just th enumbers)

		Linus