On Mon, Mar 18, 2013 at 2:32 PM, Jeff King <p...@peff.net> wrote:
> 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
>   [current master, compiled with -O3 for comparison]
>   real    0m45.588s
>   user    0m45.088s
>   sys     0m0.312s
>   [revert 1a812f3 (i.e., go back to memcmp), -O2]
>   real    0m44.358s
>   user    0m43.876s
>   sys     0m0.316s
>   [open-code first byte, fall back to memcmp, -O2]
>   real    0m43.963s
>   user    0m43.568s
>   sys     0m0.284s
> 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.

What gcc and glibc versions are you using? With gcc 4.5.3 I got "repz
cmpsb" after reverting the patch, just like what Ingo described
(although interestingly it ran a bit faster than current master, glibc
2.11.2 on Atom D510 32 bit). gcc 4.6.3 -O2 (on another machine, 64
bit) produced a call to libc's memcmp instead of "repz cmpsb". I guess
if "repz cmpsb" is what we are against, then we could pass
-fno-builtin-memcmp (potential impact to other parts of git though).
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to