On Thu, 6 Aug 2009, Artur Skawina wrote: > > # 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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html