On Wed, Dec 07, 2011 at 06:11:47PM +0100, René Scharfe wrote: > > $ time git grep --threads=8 'a.*b' HEAD >/dev/null > > real 0m8.655s > > user 0m23.817s > > sys 0m0.480s > [...] > > Ugh, right, Turbo Boost complicates matters. > > I don't understand the multiplied user time in the threaded case, > though. Is it caused by busy-waiting? Thomas reported similar numbers > earlier. I think it's mostly the clock speed. This processor runs at 1.86GHz but boosts to 3.2GHz. So we'd expect just the actual work to take close to twice as long. Plus it's a quad-core with hyperthreading, so 8 threads is going to mean two threads sharing each core, including cache (i.e., hyperthreading a core does not let you double performance, even though it presents itself as an extra core). And then you have context switching and lock overhead. So I can believe that it takes 3x the CPU time to accomplish the task. In an ideal world, it would be mitigated by having 8x the threads, but in this case, lock contention brings us down to less than 3x, and it's a slight net loss. -Peff -- 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