On Mon, Mar 18, 2013 at 2:32 PM, Jeff King <peff@xxxxxxxx> 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). -- Duy -- 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