[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