WP1: a kernel-aware pair policy, and what it is actually worth - #60
Merged
Conversation
This was referenced Sep 4, 2026
TobiBu
force-pushed
the
perf/svgd-kernel-cutoff
branch
from
September 5, 2026 19:29
f6a2e86 to
48d3292
Compare
The RBF Stein kernel has compact effective support, so a node pair whose closest possible separation d - r_A - r_B already exceeds a few bandwidths contributes nothing at any opening angle. build_svgd_topology gains kernel_cutoff (and svgd_phi / tree_svgd_step / run_tree_svgd gain cutoff_bandwidths = c, meaning c * h): such a pair is accepted so the walk stops descending, tagged FAR_TAG_IGNORE, and dropped by the partition. This is the traversal's pair_policy hook doing something gravity has no use for. Default is off, so nothing about the existing partition moves. Measured, at the scaling bench's own configuration (N = 1e4, sigma = 1.2, h = 0.5, theta = 0.5, leaf 32) -- and the numbers do not support the plan's reading of where the time goes: * the far field is 388,912 entries against 85,881,856 near-field pair terms. It is **0.45 % of the work**. Collapsing it cannot make the update fast. * at c = 6 the cutoff drops essentially nothing (M x1.0). A pair accepted by a size-relative MAC sits at gap ~ (1 - theta) d, so on a cloud only ~2 cutoffs across nothing reaches 6h. c = 4 gives M x1.6, c = 3 gives M x5.1 at no accuracy cost (9.12e-4 vs 8.95e-4), c = 2 gives M x405 but 5.6x the error. * even c = 2 improves the *total* term count by only 1.42x. On a fixed-density cloud (same N, sigma = 2.59) the policy behaves exactly as the plan predicted -- c = 4 drops M by 1519x for an error of 1.08e-7 against 4.68e-8 -- which is the point: the mechanism is right, the regime in the paper's bench is the one where it cannot pay. The tests pin the two things that are true of the policy rather than of a configuration: the update stays within 1e-6 of exact at c = 6 on all three toy targets, and a cutoff wider than the domain reproduces the plain MAC partition exactly (the guard on the tagged-far-pair plumbing).
TobiBu
force-pushed
the
perf/svgd-kernel-cutoff
branch
from
September 5, 2026 19:36
48d3292 to
20b2d18
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Stacked on #59.
The Stein kernel
exp(-r²/2h²)has compact effective support, so a node pair whose closestpossible particle separation already exceeds the cutoff contributes nothing at any opening
angle. Gravity has no such pairs, which is why the built-in MAC has no notion of them. This
adds a
pair_policythat accepts such a pair (to stop the walk descending) and tags itFAR_TAG_IGNOREso the partition drops it.The honest part is what it is worth, which is less than it looks. At the scaling bench's
own configuration the far field is 388 912 entries against 85 881 856 near-field pair terms
— 0.45 % of the work — so removing all of it changes nothing about the crossover with
brute force. 65 % of far entries evaluate a kernel below 1e-8 and 97 % below 1e-4, and the
cutoff removes them, but they were never the cost.
Where it does pay: at
c = 3bandwidths it drops M by 5.1× for free and cuts the build236 → 176 ms at N = 2·10⁴. A size-relative MAC puts accepted pairs at gap ≈ (1−θ)d, so
c = 6on a cloud ~2 cutoffs across drops nothing at all.The policy is a hook parameter, not a rule in the tree core — [D-013] stays intact.
Evidence:
reports/YGGDRAX_perf_report.md§2 (θ and c sweeps, two disproved hypotheses).🤖 Generated with Claude Code