This patch simplifies the loop inside each worker by extracting index retrieval into a lambda function.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
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. |
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? |
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.
Why are we second-guessing the ThreadPool at all? I would think we should do
Then the thread pool is responsible for dispatching the tasks when it has available resources instead of us manually looping inside the threads.