* David Miller wrote on Sat, Jun 21, 2008 at 12:26:03AM CEST: > > I used to be able to bootstrap gcc fully in minutes on average > hardware 6 or so years ago. Those days are long gone. On my largest > 64 cpu and 128 cpu boxes it takes forever these days. > > The libjava build is notoriously not helped by parallelization because > certain compiles are extremely expensive, which effectively > single-threads the build.
Would that be compiles of object files that end up in libgcj (as opposed to the link, or stuff that depends on libgcj)? If yes, the lack of parallelism should be fixable. IIRC, then objects in libjava were built from lists of source files as a means to avoid per-object overhead of libtool and some other stuff, and to produce a bit better code[1]. Now, at least libtool compile mode overhead should be a fair bit lower than back then (upstream is a bit better, if that turns out to be significant, GCC could sync again). I don't know whether the added debug info overhead, or slightly(?) worse code generation, would be a show-stopper. There should be no need to go back to creating one object per source file, a reasonably fine-grained split should be sufficient. I don't have such a big machine to test on, though, last time I looked, on 8-way things looked not too bad. Have I overlooked something? Has anybody ever measured the code generation improvements that [1] brought? Cheers, Ralf [1] <http://gcc.gnu.org/ml/java-patches/2005-q2/msg00429.html>
