Change Details

As the comment says: > + // Damage control threading. > + // > + // There are no heuristics to figure out how many threads makes sense to spawn, > + // all while rolling with all available cores hw threads starts being detrimental > + // to performance really early. > + // > + // Work around by putting a hard cap unless the user explicitly requested a certain amount. > + // > + // See https://discourse.llvm.org/t/avoidable-overhead-from-threading-by-default/69160 > + // for more details. With the link above you can see I brought it upstream, but it does not seem to be considered a problem despite their own results showing the machinery does not scale(!). The recommendation is to make sure to pass --threads=1 which given the above state should probably be default instead, requiring people to provide a different argument if they *want* threading. An alternative "If some users don’t like the default, they can create a ld.lld shell script." does not make sense either -- add fork + exec overhead only to damage control lld's feature which was supposed to improve performance. With admission that some degree of threading ultimately does help reduce total real time, the proposed simple patch is an easy middle ground: you still get the threading which provides *some* benefit in real time reduction, but is no longer happy to eat everything past laptop scale. I de facto proposed it upstream but see above.

As the comment says: > + // Damage control threading. > + // > + // There are no heuristics to figure out how many threads makes sense to spawn, > + // all while rolling with all available cores hw threads starts being detrimental > + // to performance really early. > + // > + // Work around by putting a hard cap unless the user explicitly requested a certain amount. > + // > + // See https://discourse.llvm.org/t/avoidable-overhead-from-threading-by-default/69160 > + // for more details. With the link above you can see I brought it upstream, but it does not seem to be considered a problem despite their own results showing the machinery does not scale(!). The recommendation is to make sure to pass --threads=1 which given the above state should probably be default instead, requiring people to provide a different argument if they *want* threading. An alternative "If some users don’t like the default, they can create a ld.lld shell script." does not make sense either -- add fork + exec overhead only to damage control lld's feature which was supposed to improve performance. With admission that some degree of threading ultimately does help reduce total real time, the proposed simple patch is an easy middle ground: you still get the threading which provides *some* benefit in real time reduction, but is no longer happy to eat everything past laptop scale. Note I proposed the idea upstream but it was not considered viable.

As the comment says: > + // Damage control threading. > + // > + // There are no heuristics to figure out how many threads makes sense to spawn, > + // all while rolling with all available cores hw threads starts being detrimental > + // to performance really early. > + // > + // Work around by putting a hard cap unless the user explicitly requested a certain amount. > + // > + // See https://discourse.llvm.org/t/avoidable-overhead-from-threading-by-default/69160 > + // for more details. With the link above you can see I brought it upstream, but it does not seem to be considered a problem despite their own results showing the machinery does not scale(!). The recommendation is to make sure to pass --threads=1 which given the above state should probably be default instead, requiring people to provide a different argument if they *want* threading. An alternative "If some users don’t like the default, they can create a ld.lld shell script." does not make sense either -- add fork + exec overhead only to damage control lld's feature which was supposed to improve performance. With admission that some degree of threading ultimately does help reduce total real time, the proposed simple patch is an easy middle ground: you still get the threading which provides *some* benefit in real time reduction, but is no longer happy to eat everything past laptop scale. I de factoNote I proposed itthe idea upstream but see abovet it was not considered viable.