On 04/03/2013 09:27 AM, Simon Baldwin wrote:
Suppose you had a month in which to reorganise gcc so that it builds
its 3-stage bootstrap and runtime libraries in some massively parallel
fashion, without hardware or resource constraints(*). How might you
approach this?
I'm looking for ideas on improving the build time of gcc itself. So
far I have identified two problem areas:
One of the things I've noticed is multilib library targets don't build
in parallel.
I noticed this mostly in libjava, but it applies to others that use the
automake generated bits. Basically the i686 version of the library
won't start building until the x86_64 version has completed due to
Makefile lameness.
- Structural. In a 3-stage bootstrap, each stage depends on the
output of the one before. No matter what does the actual compilation
(make, jam, and so on), this constrains the options.
- Mechanical. Configure scripts cause bottlenecks in the build
process. Even if compilation is offloaded onto something like distcc,
configures run locally and randomly throughout the complete build,
rather than (say) all at once upfront. Source code compilation
blocks until configure is completed.
One way to improve the first might be to build the runtime libraries
with stage2 and interleave with stage3 build on the assumption that
comparison will pass. That probably won't produce an exciting
speedup, likely modest at best.
Well, you could (for example) start building libraries as soon as the
appropriate front-end bits are in place. So for example, if we have a
library that is just C code, it can start building as soon as the C
front-end has been build. C++ bits start as soon as the C++ front-end
is built, etc. You could possibly get fine grained control and
partially build libraries which use multiple languages.
That'd be a huge structural overhaul as well.
In my experience, running the testsuite takes longer than the build. So
you could fire up the testsuite as soon as stage2 is built so that the
testsuite and stage3 are running together.
Sharing configury caches was a significant help in the huge single
source trees that Cygnus used to use (gcc, binutils, gdb, flex, bison,
sim, tcl, tk, expect, make, etc etc all in one source tree sharing
config.cache). Might be able to do that again and possibly do it on the
target library side as well.
There may be other ideas floating out there.
jeff
