On Sun, 2 Aug 2009, George Spelvin wrote: > > The original code was excellent, but it was optimized when the P4 was new. > After a bit of tweaking, I've inflicted a slight (1.4%) slowdown on the > P4, but a small-but-noticeable speedup on a variety of other processors. > > Before After Gain Processor > 1.585248 1.353314 +17% 2500 MHz Phenom > 3.249614 3.295619 -1.4% 1594 MHz P4 > 1.414512 1.352843 +4.5% 2.66 GHz i7 > 3.460635 3.284221 +5.4% 1596 MHz Athlon XP > 4.077993 3.891826 +4.8% 1144 MHz Athlon > 1.912161 1.623212 +17% 2100 MHz Athlon 64 X2 > 2.956432 2.940210 +0.55% 1794 MHz Mobile Celeron (fam 15 model 2) It would be better to have a more git-centric benchmark that actually shows some real git load, rather than a sha1-only microbenchmark. The thing that I'd prefer is simply git fsck --full on the Linux kernel archive. For me (with a fast machine), it takes about 4m30s with the OpenSSL SHA1, and takes 6m40s with the Mozilla SHA1 (ie using a NO_OPENSSL=1 build). So that's an example of a load that is actually very sensitive to SHA1 performance (more so than _most_ git loads, I suspect), and at the same time is a real git load rather than some SHA1-only microbenchmark. It also shows very clearly why we default to the OpenSSL version over the Mozilla one. NOTE! I didn't do multiple runs to see how stable the numbers are, and so it's possible that I exaggerated the OpenSSL advantage over the Mozilla-SHA1 code. Or vice versa. My point is really only that I don't know how meaningful a "50 x 1M SHA1" benchmark is, while I know that a "git fsck" benchmark has at least _some_ real life value. 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