Improve parallel scaling of e-matching - #954
Conversation
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #954 +/- ##
==========================================
+ Coverage 86.65% 86.82% +0.17%
==========================================
Files 95 95
Lines 29695 30591 +896
==========================================
+ Hits 25732 26561 +829
- Misses 3963 4030 +67 ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
Merging this PR will not alter performance
Comparing Footnotes
|
|
From running Update: numbers from nightly are mostly consistent with the above
But the packed trie PR #959 shows some significant speedups.
|
|
I think the llama slowdown is due to the buggy variable ordering heuristic that codex snuck in; it's reverted in the packed-trie branch. |
a384d25 to
90ebda4
Compare
Add private worker queues and scheduler metrics, partition generic joins by physical index shard, and retain prepared index handles for recursive probes.
6ee8312 to
e4ebef2
Compare
|
new perf numbers using this script (I had another run using the existing bench.py that's worse but I think it's the artifact of that script. The updated regression is much slower.) gemma4_moe.egg is up to ~10% slower |
(branched off of
perf-shared-trie-nodes)This change improves parallel e-matching scaling with a few optimizations:
Arc::clonecalls with index construction: handles on shared indexes are grabbed before the plan starts running to avoid big clone calls. This alone was a large win.spawn_localmethod onto the thread pool that allows for work to be appended to a local deque first, only migrating to the global queue if sufficient threads are stalled. This appears to help cases where there isn't a lot of parallelism to expose. The thread pool essentially sprayed data randomly across threads, which makes cache locality much harder to achieve. (The original morsel-driven parallelism paper talks about this too). Local spawns maintain locality while still improving parallel utilization if there's a lot of skew.To evaluate this I had codex write up a benchmark using the dataset and queries from the Honeycomb paper. This is just a single query over a large dataset, so it's a helpful test case for this part of the code: other egglog benchmarks have complex schedules and many rules that we parallelize across sometimes.
Here are the overall results on my m4 max laptop:
(Note that M4 max only has 12 P-cores, so some amount of flattening after 12 is expected. Still, I suspect there's more to do here)