Re: Git and GCC

From: Jeff King <peff@peff.net>
Date: Dec 7, 2007, 06:50 UTC
Message-ID: <20071207065047.GB13101@coredump.intra.peff.net>
In-Reply-To: <alpine.LFD.0.99999.0712061246120.555@xanadu.home>

On Thu, Dec 06, 2007 at 01:02:58PM -0500, Nicolas Pitre wrote:

Show 7 quoted lines

> > 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.

Show 5 quoted lines

> 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