Re: Make GIT_USE_LOOKUP default?
- From
Junio C Hamano <gitster@pobox.com>
- Date
- Mar 18, 2013, 16:44 UTC
- Message-ID
- <7vtxo8ody3.fsf@alter.siamese.dyndns.org>
- In-Reply-To
- <20130318073229.GA5551@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
Show 27 quoted lines
> By the way, looking at that made me think for a few minutes about > hashcmp, and I was surprised to find that we use an open-coded > comparison loop. That dates back to this thread by Ingo: > > http://article.gmane.org/gmane.comp.version-control.git/172286 > > I could not replicate his benchmarks at all. In fact, my measurements > showed a slight slowdown with 1a812f3 (hashcmp(): inline memcmp() by > hand to optimize, 2011-04-28). > > Here are my best-of-five numbers for running "git rev-list --objects > --all >/dev/null" on linux-2.6.git: > > [current master, compiled with -O2] > real 0m45.612s > user 0m45.140s > sys 0m0.300s > ... > [revert 1a812f3 (i.e., go back to memcmp), -O2] > real 0m44.358s > user 0m43.876s > sys 0m0.316s > ... > I wonder why we get such different numbers. Ingo said his tests are on a > Nehalem CPU, as are mine (mine is an i7-840QM). I wonder if we should be > wrapping the optimization in an #ifdef, but I'm not sure which flag we > should be checking.
FWIW, I am getting something like this on my
$ grep 'model name' /proc/cpuinfo | uniq -c 4 model name : Intel(R) Core(TM)2 Quad CPU Q9450 @ 2.66GHz
The same "rev-list --objects --all >/dev/null", best of five:
[current master, compiled with -O2] real 0m39.956s user 0m39.562s sys 0m0.396s
[revert 1a812f3 (i.e., go back to memcmp), -O2] real 0m42.161s user 0m41.879s sys 0m0.284s
It could be that the difference may be how well memcmp() is optimized, no? My box runs Debian with libc6 2.11.3-4 and gcc 4.4.5.