GCC Multi-Threading Ideas

Nicholas Krause xerofoify@gmail.com
Fri Jan 24 10:34:00 GMT 2020

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_RRgSCtRyYgMHjV0itW8iOzJXpTdHYIpC9gUMj 
>>> 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. 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.


More information about the Gcc mailing list