On Thu, Dec 06, 2007 at 01:02:58PM -0500, Nicolas Pitre wrote: > > What is really disappointing is that we saved > > only about 20% of the time. I didn't sit around watching the stages, but > > my guess is that we spent a long time in the single threaded "writing > > objects" stage with a thrashing delta cache. > > Maybe you should run the non threaded repack on the same machine to have > a good comparison. Sorry, I should have been more clear. By "saved" I meant "we needed N minutes of CPU time, but took only M minutes of real time to use it." IOW, if we assume that the threading had zero overhead and that we were completely CPU bound, then the task would have taken N minutes of real time. And obviously those assumptions aren't true, but I was attempting to say "it would have been at most N minutes of real time to do it single-threaded." > And if you have only 2 CPUs, you will have better performances with > pack.threads = 2, otherwise there'll be wasteful task switching going > on. Yes, but balanced by one thread running out of data way earlier than the other, and completing the task with only one CPU. I am doing a 4-thread test on a quad-CPU right now, and I will also try it with threads=1 and threads=6 for comparison. > And of course, if the delta cache is being trashed, that might be due to > the way the existing pack was previously packed. Hence the current pack > might impact object _access_ when repacking them. So for a really > really fair performance comparison, you'd have to preserve the original > pack and swap it back before each repack attempt. I am working each time from the pack generated by fetching from git://git.infradead.org/gcc.git. -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
