If you had a month to improve gcc build parallelization, where would you begin?
Diego Novillo
dnovillo@google.com
Thu Apr 4 13:32:00 GMT 2013
On 2013-04-04 04:49 , Richard Biener wrote:
> But yes, testing is the most time-consuming part, and the testsuite
> harness overhead is big. A combined bootstrap&test target could
> indeed interleave target library build and testing. General improvements
> to parallel testing support (hack upstream dejagnu?) to be less
> statically divided would also help.
Yes. Fortunately, the testsuite is the easiest component to
parallelize. Internally, I've implemented a setup over our build system
to split all the files in all the testsuite directories in N independent
sets. This brings testing times from 1.5hrs down to 10min. There are
some issues, however. Some directories have implicit dependencies:
http://gcc.gnu.org/ml/fortran/2013-02/msg00106.html.
> Not sure if improving things for people with distributed compile setup
> will help many people. It isn't my testing setup at least. At least
> make sure you don't regress things for people without distributed
> compile ;)
Agreed. make -j should be first priority. Multicores are easier to
come by than clusters. And improvements in single-box builds, will also
help distributed setups (better dependencies).
Diego.
More information about the Gcc
mailing list