GCC Multi-Threading Ideas

[Nicholas Krause]

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.

Nick
>>
>>
>