On Wed, 27 Apr 2005 16:52:25 -0400, Paul Koning <[EMAIL PROTECTED]> said:
> However, I can always tell when a GCC build has hit the libjava build > -- that's when the *whole system* suddenly slows to a crawl. Maybe > it comes from doing some processing on 5000 foo.o files all at > once... :-( It's also too bad the final steps of the libjava build aren't more parallelizable, though I can't say I have any productive suggestions to add there. I just tried a C/C++ bootstrap and a C/C++/Java bootstrap on a four-processor machine; the latter took 2.6 times as long as the former, and for most of the non-compilation part of the libjava build, three of the processors were sitting around being bored. (Not that I really know exactly what was causing the delays; maybe the disk and memory were being stressed enough by the single processor that was active.) This also showed up a little in the C build: while make found other stuff to do while gen-attrtab was going on, shortly after it started compiling insn-attrtab.c, make ran out of other files to compile. Not that I'm really complaining: you can get quite a lot of mileage out of multiple CPUs as it is, more than enough (in my opinion) to justify purchasing some nice build servers by software shops that do a lot of GCC work. (I won't post the actual bootstrap times out of fear of being lynched.) This might show up more as people start moving towards dual-core and/or multiple CPU systems even on the low end. David Carlton [EMAIL PROTECTED]
