This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: GCC Multi-Threading Ideas

On 1/24/20, Richard Earnshaw (lists) <> wrote:
> On 24/01/2020 10:27, Jonathan Wakely wrote:
>> On Fri, 24 Jan 2020 at 03:39, Nicholas Krause <>
>> wrote:
>>> 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. The problem has
>>> to
>>> do with large build machines with CPUs with more cores than this or as
>>> is becoming
>>> more common on mainstream systems.
>> And make scales well beyond 8 processes (not threads) on such machines.
> The problem isn't make, per se, or even gcc.  It's the build system as a
> whole.
> On a highly multi-core machine, gcc itself hits the bottle-neck called
> configure.  That's serial, run *many* times (especially when there are
> many multilibs) and dominates build time.
> On high multi-core machines, gcc's 15-minute system load gets no-where
> near to the number of threads on the machine because of this.
> R.

It would be great if we could get some new autotools releases some
time to help with this; autoconf in particular hasn't had an update in
several years now AFAIK. While automake has had updates more recently
than autoconf, they've mostly just been to the automake part itself
and not to the aclocal program that comes with it, and aclocal in
particular is another bottleneck for people who regenerate the build
system files (although it could just be that way in my case because I
have so many m4 macro files installed on my system for it to search
thru for macros every time...)

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]