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
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
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.
ccache mailing list