On Freitag, 24. Januar 2020 04:38:48 CET Nicholas Krause wrote: > On 1/23/20 12:19 PM, Nicholas Krause wrote: > > On 1/23/20 3:39 AM, Allan Sandfeld Jensen wrote: > >> On Montag, 20. Januar 2020 20:26:46 CET Nicholas Krause wrote: > >>> Greetings All, > >>> > >>> Unfortunately due to me being rather busy with school and other > >>> things I > >>> will not be able to post my article to the wiki for awhile. However > >>> there is a rough draft here: > >>> https://docs.google.com/document/d/1po_RRgSCtRyYgMHjV0itW8iOzJXpTdHYIpC9 > >>> gUMj > >>> > >>> Oxk/edit that may change a little for people to read in the meantime. > >> > >> This comment might not be suited for your project, but now that I > >> think about > >> it: If we want to improve gcc toolchain buildspeed with better > >> multithreading. > >> I think the most sensible would be fixing up gold multithreading and > >> enabling > >> it by default. We already get most of the benefits of multicore > >> architectures > >> by running multiple compile jobs in parallel (yes, I know you are > >> focusing on > >> cases where that for some reason doesn't work, but it is still the > >> case in > >> most situations). The main bottleneck is linking. The code is even > >> already > >> there in gold and have been for years, it just haven't been deemed > >> ready for > >> being enabled by default. > >> > >> Is anyone even working on that? > >> > >> Best regards > >> Allan > > > > Allan, > > You would need both depending on the project, some are more compiler > > bottle necked and others linker. I mentioned that issue at Cauldron as > > the other side would be the linker. > > > > Nick > > Sorry for the second message Allan but make -j does not scale well > beyond 4 or > 8 threads and that's considering a 4 core or 8 machine.
It doesn't? I generally build with -j100, but then also use icecream to distribute builds to multiple machines in the office. That probably also makes linking times more significant to my case. 'Allan