Three-mode outer-classifier A/B on the headless game path, nested refinement off in all
modes, clean and diagnostics off. Runs made by the forked Codex session; the table was
assembled and checked by me from its logs (Saved/OuterABMode*_20260912.log,
OuterABMove*Headless_20260912.log).
static ready p95 mode0 182.4-182.7 mode1 189.7-194.8 mode2 190.0-194.7 ms
gen p95 mode0 124.9-127.0 mode1 139.1-140.6 mode2 140.3-141.3 ms
worker CPU mode0 184.9-193.5 mode1 201.2-202.3 mode2 201.2-201.3 s
density mode0 18.05M mode1 21.89M mode2 21.89M
moving ready p95 mode0 198.9 mode1 208.0 mode2 210.7 ms
density mode0 57.7M mode1 69.6M mode2 69.6M
The outer classifier costs more than it saves: with it removed (mode 0), every latency
figure improves and density calls drop by about 18%. Mode 0 also cannot remove geometry,
because it skips nothing.
Mode 2 (reuse the validation samples as the mesher's core grid) recorded 0 reuse tiles in
every run. That is by design, not a bug: the grid is only reused when validation DISPROVES
a uniform verdict, and it disproved none. Mixed tiles, which are the ones that need a
grid, never run validation at all.
Recommendation recorded in WORK-NEXT.md, pending the owner: default the outer classifier
mode to 0. The code default is NOT changed in this commit.
CORRECTION to f204413, whose message says the nested classifier's 3.5x could not be
reproduced. That was my error. I passed the streaming console variable
-voxel.UseBlockEarlyOut=1 to the export commandlet, which reads its own -blockearlyout=
argument (VoxelForgeExploreCommandlet.cpp:381, :1093), so both of my runs had nested
refinement off. Re-run with the right flag:
-blockearlyout=0 0.553 / 0.572 s
-blockearlyout=1 2.036 / 2.060 s 3.6x, geometry SHA-256 b3e5f4c3..9b377 identical
The 3.5x was real. Turning nested refinement off in streaming (f204413) was worth it,
and Sol's reading of the table was right where mine was wrong.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01VZS94UH8bSsBeg5sZaxe2Y
Written by the classifier-fix Codex round before it was closed. The classifier is a
second evaluator -- interval proofs, exact certificates and final-field validation --
beside the canonical lowered one, and the runtime can validate the same tile again
before meshing. Any classifier kept long-term must consume the lowered representation
and reusable density data.
That round's other uncommitted edit was NOT kept: it flipped
GVoxelForgeOuterClassifierMode 1 -> 0, turning the outer classifier off by default.
That was A/B setup for an unfinished experiment, not a measured decision, so the
committed default (1, classifier on) is restored.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01X9DLqyXrJxG4TojzDrSmVw
Two WORK-NEXT items, one null result and one confirmed removal. Item 4 untouched.
ITEM 3 -- CANCEL OBSOLETE WORK AND PRIORITISE THE FLOOR: NULL RESULT
Clean -nullrhi, diagnostics off, 800 cm/s, 200 m of travel:
before after
request->ready p95 0.369117 s 0.367612 s
queue wait p95 0.066949 s 0.064483 s
generation p95 0.287926 s 0.283642 s
p95 travel distance 2.952938 m 2.940894 m
obsolete aborts 0 12
Flat. Aborting obsolete tiles, sorting from the true pawn position and prioritising the
occupied/next tile changed request-to-ready by 0.4%.
⭐ AND THE NULL RESULT IS ITSELF THE FINDING. Look at the split: queue wait is 65 ms of a
368 ms p95; generation is 284 ms. **The queue was never the problem, so reordering it
cannot help.** Only 12 tiles in a 200 m run were obsolete enough to abort. The floor is
late because generation is slow, not because work is badly ordered -- item 3 establishes
that by exclusion, which is worth more than the 0.4%.
The machinery is kept: it is correct, it costs nothing, and it will matter once
generation is fast enough for ordering to be the binding constraint.
ITEM 5 -- VERDICT CACHE REMOVED. It was pure overhead.
Clean moving-session audit:
outer calls/probes/hits 2,109 / 2,109 / 0
nested calls/probes/hits 19,904 / 19,904 / 0
enclosing hits 0
stores 15,877, evictions 15,365
⇒ It stored 15,877 proofs, evicted 15,365 of them, and hit ZERO times. A moving player
visits unique regions; the cache was filling and thrashing a 512-entry table under a
global lock for no benefit. Same-binary A/B: request p95 0.367645 vs 0.365978,
generation p95 0.285559 vs 0.285992 -- neutral within noise, so its cost was the lock and
the linear scans rather than time we can see.
Removed: the global cache, its lock, the entry table, the invalidation path, the
cache-only profiler fields and the synthetic probe. The proof classifier stays.
⚠️ I asked for this cache two days ago on the strength of a commandlet measurement that
re-visited the same region repeatedly. That access pattern is nothing like a moving
player, and I should have said so when specifying it.
VERIFIED BY ME: build 0 errors; export 0.563 / 0.565 / 0.566 s (35de59b was 0.545-0.563,
flat as expected); geometry SHA-256 b3e5f4c3..9b377 UNCHANGED; capability 20,830 /
10,909, connected.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_012aheo2crrZmHuYtPpdY2Cb
Ordered by importance then size. Sol (read-only, xhigh) audited experimental @ aa62971
against main and delivered the two-sentence diagnosis this queue is built on:
"The operator abstraction leaked into the innermost loop, and streaming treats
'work submitted/applied' as 'safe to stand on.'"
Two corrections it made to us, both recorded in the doc:
- The fall-through is NOT a removed correctness barrier. main has no spawn gate
either, marks tiles loaded before applying, and collides only LOD0. It was fast
enough to hide the race. The owner's evidence was real; the inference was not.
- The loop inversion did not recover the 8x because it traded PER-SAMPLE
short-circuiting (~70% of deep-solid samples skipped the cave suite) for per-block
pruning. The fix is lowering the operator graph into a fused evaluator, not more
dispatch removal.
It also found that RMC cooks collision ASYNCHRONOUSLY and we never record
cook-complete -- apply_s ends at submission, so nothing we have ever measured says
when physics could actually collide.
Reading Plugins/RealtimeMeshComponent is now permitted for item 1, READ ONLY, by the
owner's decision.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_012aheo2crrZmHuYtPpdY2Cb
Fr0zkaandClaude Opus 5