Thread (2 messages) flat view 2 messages, 2 authors, 2016-06-15

Re: Make GIT_USE_LOOKUP default?

From: Junio C Hamano <hidden>
Date: 2016-06-15 22:56:26

Jeff King [off-list ref] writes:
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.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help