This is an archive of the discontinued LLVM Phabricator instance.

[clang][deps] NFC: Simplify worker loop
ClosedPublic

Authored by jansvoboda11 on Mar 1 2023, 11:53 AM.

Details

Summary

This patch simplifies the loop inside each worker by extracting index retrieval into a lambda function.

Diff Detail

Event Timeline

jansvoboda11 created this revision.Mar 1 2023, 11:53 AM
Herald added a project: Restricted Project. · View Herald TranscriptMar 1 2023, 11:53 AM
Herald added a subscriber: ributzka. · View Herald Transcript
jansvoboda11 requested review of this revision.Mar 1 2023, 11:53 AM
Herald added a project: Restricted Project. · View Herald TranscriptMar 1 2023, 11:53 AM
Herald added a subscriber: cfe-commits. · View Herald Transcript
benlangmuir added inline comments.Mar 1 2023, 12:09 PM
clang/tools/clang-scan-deps/ClangScanDeps.cpp
804

Why are we second-guessing the ThreadPool at all? I would think we should do

for (unsigned Index = 0; E = Inputs.size(); Index + E; ++Index) {
  Pool.async([Index, &]{ ... });
}

Then the thread pool is responsible for dispatching the tasks when it has available resources instead of us manually looping inside the threads.

jansvoboda11 added inline comments.Mar 1 2023, 12:47 PM
clang/tools/clang-scan-deps/ClangScanDeps.cpp
804

I guess it was originally done this way because we have a number of DependencyScanning{Tool,Worker} instances (the same number as there are threads in the pool) we want to reuse to get the advantage of local caching in DependencyScanningWorkerFilesystem. I guess having one Worker instance "pinned" to one thread might get us better memory access patterns? (I'm just guessing here.)

We could implement your simplification and keep the "pinning" if the thread pool gave us index of the thread the async task is running on. But it doesn't seem like we have that API.

That means we'd probably need to implement some Worker queue each async task would take from. I'm not sure that's better/simpler than monotonically increasing input index.

Maybe @Bigcheese can explain this in more detail?

benlangmuir accepted this revision.Mar 1 2023, 1:17 PM

I guess it was originally done this way because we have a number of DependencyScanning{Tool,Worker} instances

Oh of course, this makes sense. Yeah we could maybe find a different way to do it if we care, but this is a sufficiently good reason to keep doing what we're doing and shouldn't hold you up.

Thanks for explaining; LGTM.

This revision is now accepted and ready to land.Mar 1 2023, 1:17 PM
This revision was automatically updated to reflect the committed changes.