On 25-11-2010 13:08, Wilson Snyder wrote:

We have about 100 machines, with about 400 cores - a mix of
older 2 socket up to modern 12 core systems.  Compiles are
~~10% of the work load.  The NFS server with CCACHE_DIR has
6 RAID-5 disks; it does other things too, not just ccache.
We decided to bond 4 ethernet ports into the NFS server as
we saw occasional bottlenecks exceeding 1GbE out of that

Quite interesting. Why does the compilers only take 10% of the time? Are you saying that ccache does the rest 90%?

Managing CIFS/NFS isn't a big deal mostly because most IT
departments already know how to manage CIFS/NFS.  Also, I'd
be a little surprised if your site doesn't have shared CIFS
drives already.

Sure we have. Actually I took the time to try it out with ccache v2.4 (since it's the only Windows version currently available, excluding the various patches that may or may not work on the latest version). To my surprise it was so slow that it simply didn't make any sense. In many cases ccache took longer time than the real compiler would have to do the compilation.

In our environment we're already using Xoreax Incredibuild to speed up the compilation. While Incredibuild is good and does speed up the build then it doesn't solve the problem of re-doing the same steps multiple times for each developer. This is why I believe ccache would enhance Incredibuild even further.

I should say that if we could be compiling on linux only then gcc is so fast compared with Visual C++ that even a single core machine can compare with a Incredibuild cluster of 3-4 machines. Unfortunately we're stuck with these tools though...

I see that memcached is limited to 1 mb data per key. Naturally this
causes some troubles as many files would either not be cached or you'd
need to split it up to more keys.

Good point, forgot about that.

I'd say that this is a sacrifice possible to live with though. For majority of source files they are within the limits.

-- Henrik

ccache mailing list

Reply via email to