“Most parts are still single-threaded, and we have no interest in making
it concurrent.”
“lld depends on LLVM libObjects and libDebugInfo to read object files and debug info. libObjects and libDebugInfo have more features than lld needs”
Well, there’s some room for improvement in performance for anyone looking for project ideas. One can attempt to parallelize the parts that are hard to parallelize. Maybe also throw a super-optimizer at the fast paths in the code. That’s worth trying on everything just to see what happens. :)
It looks like the difference in their example was 5 seconds versus 3 seconds as a theoretical minimum. They probably thought at this point the gains in speed over the complexity just isn’t worth the effort in developer time.
That would make a lot of sense. It’s just demoscene fun to optimize at that point. One exception might be resource-constrained, parallel systems but I cant think of a practical example.
“Most parts are still single-threaded, and we have no interest in making it concurrent.”
“lld depends on LLVM libObjects and libDebugInfo to read object files and debug info. libObjects and libDebugInfo have more features than lld needs”
Well, there’s some room for improvement in performance for anyone looking for project ideas. One can attempt to parallelize the parts that are hard to parallelize. Maybe also throw a super-optimizer at the fast paths in the code. That’s worth trying on everything just to see what happens. :)
It may not be worth the additional complexity though.
True! Especially given most companies with codebases that large can afford to add some servers.
It looks like the difference in their example was 5 seconds versus 3 seconds as a theoretical minimum. They probably thought at this point the gains in speed over the complexity just isn’t worth the effort in developer time.
That would make a lot of sense. It’s just demoscene fun to optimize at that point. One exception might be resource-constrained, parallel systems but I cant think of a practical example.