Repository navigation
Reduce threading overhead #2740
Description
Our threading overhead seems significant. When I measure a fixed pure computational workload, replacing the body of a pass like precompute to instead just do some silly work, then measuring with time, the user time is the same when BINARYEN_CORES=1 (use 1 core) and when running normally with all cores. That makes sense since the total actual work is added up in user, and it's the same. And there isn't much synchronization overhead that slows us down.
But that's not the typical case when running real passes, the user for multi-core can be much higher, see e.g. #2733 (comment) and I see similar things locally with user being 2-3 larger when using 8 threads.
This may be a large speedup opportunity. One possibility is that we often have many tiny functions, and maybe switching between them is costly? Or maybe there is contention on locks (see that last link, but this happens even after that PR which should get rid of that).
The thread-pool using code for running passes on functions is here:
Line 591 in dc5a503
Activity
tlively commentedon Apr 9, 2020
Some TODOs along this vein:
Typecontain aSmallVecrather than an indexAs multivalue becomes common, we will also want to:
kripken commentedon Apr 10, 2020
Measuring with
perf statafter #2745 things look a lot better.usertime is still higher than expected, but after investigating withperfI suspect that might be slightly misleading (or maybeperfis wrong...).It does seem though that we gain almost nothing from using the reported system cores versus half of them. My guess is hyperthreading doesn't really help us since we are very CPU work bound (no I/O to wait on, and we are cache-friendly by having small data structures and running as many passes as possible on a single function before moving on to the next). But I'm not sure we can do anything about that.
vapier commentedon Mar 14, 2022
fwiw, still seeing huge overhead with the v105 release