[PATCH] D101699: [Support/Parallel] Add a special case for 0/1 items to llvm::parallel_for_each.
Fangrui Song via Phabricator via llvm-commits
llvm-commits at lists.llvm.org
Mon Jan 17 12:44:41 PST 2022
MaskRay added a comment.
In D101699#2736758 <https://reviews.llvm.org/D101699#2736758>, @rnk wrote:
> Change looks good.
>
> In the long run, we should try to build on an existing C++17 parallel algorithms library, such as the pstl in our own monorepo. I don't know how far off it is before we can raise the LLVM toolchain requirements to C++17, and after that, how much platform support will hold us back, but maybe we can hack the pstl into the LLVM build if it becomes a sticking point.
>
> The important thing for LLVM is that we express our code using well-known, deterministic parallel algorithms, and we can pick up better implementations later.
Keeping LLVM's own version provides some flexibility. E.g. when lld is writing output sections parallely, we may tune the function to have a better `TaskSize`.
I tested that for -DCMAKE_BUILD_TYPE=Release clang, using a [[ https://gist.github.com/MaskRay/540e7bb31408afcee2b827140bef33e3 | fixed `TaskSize==128` ]] is 1.02x as fast as the current code, though it has no noticeable difference when linking chrome.
Such preference may not be expressable with the C++ STL.
Another thing we need to think about is code bloat. Many template heavy libraries expand to huge amount of code. For some programs like a linker, we favor calling `parallel*` in many places. The expanded code may be significant.
(I think mold has experienced this.)
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D101699/new/
https://reviews.llvm.org/D101699
More information about the llvm-commits
mailing list