This is the mail archive of the gcc-help@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: reduce compilation times?


Sven Eschenberg writes:

 > I am not sure about ccache, but I thought it does some file and
 > preprocessing caching (not exactly sure, how it works, I thought,
 > it kinda gets called instead of the preprocessor or at least before
 > the PP).

That's right: if the file has been compiled before, ccache bypasses
compilation entirely.

 > Anyway, what I meant: Compiling a package like firefox, glibc
 > etc. with ccache gives you some speed increase, but it is small
 > compared to uncompressing the source directly into a ram disk and
 > build everything in there.

That sounds pretty surprising to me.  How is a RAM disk going to be so
much faster than. say, /tmp?  I suppose there's no overhead of writing
the files back to disk after updating them, but thet's usually done in
the background anyway.  "make -jN" is usually enough to swallow up any
rotational latency.  But when I'm compling, all CPU cores are usually
at 90% plus; the compiler certainly isn't waiting for disk.  That RAM
disk is going to get me 10% more at best.

 > Combining both didn't seem to give additional reproduceable
 > benefit, but I gotta admit, never tried to put ccache's data into a
 > ramdisk too, since I don't have enough ram for that on sufficently
 > big enough packages.  If -j2 speeds things, it's mostly because of
 > the kernel's scheduling, I assume.
 > 
 > The only box I got left, which is Uniprocessore and doesn't have
 > HT/Multiple cores didn't really compile faster with -j2 - Then
 > again it is a server, which has a certain minor load anyway all the
 > time, that's why I assume -j2 on Uniprocessor only benefits from
 > scheduling strategies.

The main purpose of -j2 on a uniprocessor is to absorb any disk
latency: when one process blocks because a file is not ready, another
process has something useful to do.  It's not a huge win when building
gcc, but it is significant.  It is very usefule when building on an
NFS-mounted drive.

Andrew.

-- 
Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, UK
Registered in England and Wales No. 3798903


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]