[PATCH] D131247: [ELF] Parallelize writes of different OutputSections
Andrew Ng via Phabricator via llvm-commits
llvm-commits at lists.llvm.org
Fri Aug 12 06:45:42 PDT 2022
andrewng added a comment.
> Some `parallel*` in SyntheticSections.cpp (e.g. `MergeNoTailSection::writeTo`) is now serial due to limitation of llvm/Support/Parallel.h, e.g. GdbIndexSection::writeTo, MergeNoTailSection::writeTo. Sometimes (in all workloads I have tested) overlapping their write with other output sections seems better than spending all threads in parallelizing them and writing output sections serially.
That is a shame. I think keeping the "parallel for" in the BYTE handling code is fine, I was just commenting that it wouldn't be parallel given the current circumstances. Hopefully, at some point the limitation in the parallel support can be improved.
> Also, --time-trace may be useful to analyze synchronous operations. For asyncParallelFor, te "Write ..." time may be significantly smaller.
Unfortunately, the `--time-trace` didn't really tell me anything I didn't already know, i.e. the writing of the output sections is taking significantly longer, everything else is about the same.
However, I have isolated it to the `.debug` sections. My "fast" test cases didn't have any debug info, where as the "slow" test cases all had some debug info. Did you test with debug info? I think the key thing about debug info is that it's large and has relatively few input sections which is why the minimum task size figure makes such a significant difference. This would lead me to suggest that having multiple threads concurrently writing out different large output sections does not scale well on Windows.
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D131247/new/
https://reviews.llvm.org/D131247
More information about the llvm-commits
mailing list