On 1/24/20 3:18 AM, Allan Sandfeld Jensen wrote:
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
Allan,
I ran a gcc build on a machine with make -j32 and -j64 that had 64 cores. There
was literally only
a 4 minute increase in build speed. Good question through.
Nick
