Files
VoxelForge/Standalone/Research/WorldAssemblerM3/Linux77/REPORT.md
T
Fr0zkaandClaude Opus 5.5 5e091d254c profile: in-process SIGPROF sampler + exclusive route/phase census (L77); closes to 0.1%
Opt-in (L77 build + --linux77-profile; compiled out by default, 0.02% handler cost).
FI/TN cost account closes against direct grid-fill timing within 0.15% (LOD0-2 bins within 1.4%).
Passage carving = 66% of LOD0-2 CPU (52-54% whole view), passage support 10-14%, base packed
+ analytic field ~3%. Hotspots: value noise 17%, lower_bound in VisitNearestPassageSpatialNode
14%, ApplyResolvedStratePassageCarves 6.5%. LOD0/1 complete LAST (4.1/4.6 s) while LOD2 is
ready at 2.2 s.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016dhxM43dnWvUu2B5Ph1iG1
2026-10-27 17:55:39 +01:00

82 lines
7.1 KiB
Markdown
Raw Blame History

This file contains ambiguous Unicode characters
This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.
# Linux77 — FI/TN whole-view cost
## Run and method
Final profile runs were FI/TN r12 and r13, source stamp `6532cc3d9ca7137b1b62a3ae1c7bc54ebffc8fa3d58a9f12740c11d2048f4a0d`. They used eight workers, LOD0–8, `hash=off`, `force_generate=off`, and no `--stream-hash`; whole-tile skips remained active (481 FI, 578 TN). The route and phase tags are enabled only in the L77 build plus `--linux77-profile`. A separate default build with the profiler compiled out emitted zero samples.
The sampler used a per-thread CPU timer on each worker and the main thread. It recorded one PC per timer delivery and expanded delayed signals by `1 + si_overrun`. Across four profiles it recorded 32,235 events / 128,923 weighted ticks, with nine timers per process, zero ring loss, and 129.06 s of profiled thread CPU. Handler CPU was 23.9 ms total (0.018%); per-run cost was 0.017–0.020%. The handler figure excludes kernel signal-delivery cost. The full per-call tag/counter overhead could not be isolated from run-to-run timing variation.
## Cold readiness
Times are from the two final profiled runs; values show mean (range). LOD readiness means every desired tile at that LOD completed.
| Ready point | FI | TN |
|---|---:|---:|
| First tile | 0.377 s (0.376–0.377) | 0.399 s (0.388–0.409) |
| 27-tile neighborhood | 0.744 s (0.714–0.774) | 0.563 s (0.559–0.566) |
| LOD0 | 4.139 s (4.118–4.160) | 4.046 s (3.921–4.172) |
| LOD1 | 4.618 s (4.593–4.642) | 4.233 s (4.106–4.361) |
| LOD2 | 2.226 s (2.209–2.242) | 2.040 s (1.983–2.096) |
| LOD0–2 all ready | 4.618 s (4.593–4.642) | 4.234 s (4.106–4.361) |
| Whole view ready | 4.617 s (4.593–4.641) | 4.233 s (4.105–4.360) |
LOD1 is last, so LOD0–2 completion and whole-view readiness coincide in these runs. The ~1 s target is met for the first tile and neighborhood, but not for complete LOD0–2. The compiled-out controls measured 4.54–5.55 s FI and 4.70–4.74 s TN for whole-view readiness; they emitted no sampler records. Their timing scatter is too large to infer a small instrumentation delta. This headless run measures readiness, not frame-time stutter.
## Exclusive cost account
Worker CPU is the sum of tile-worker time, averaged over r12/r13. Each cell is seconds (% of that scope); rounded values may not sum exactly. The phase split assigns field and composition work wherever it runs. MC, skirt, and refine columns contain the remaining non-field work in those caller stages, so composition inside a mesher call is not counted twice. `Other` is unclassified grid work plus the residual tile work.
| Strate / scope | Worker CPU | Base packed / analytic / other | Graph | Bands | Passages | Support | Caps + edits | Dispatch | MC | Skirts | Refine | Other |
|---|---:|---:|---:|---:|---:|---:|---:|---:|---:|---:|---:|---:|
| FI LOD0–2 | 23.02 s | 0.45 (1.9%) / 0.29 (1.3%) / 0.00 | 0.03 (0.1%) | 0.52 (2.3%) | 15.17 (65.9%) | 3.26 (14.2%) | 0.06 (0.3%) | 0.84 (3.7%) | 0.36 (1.6%) | 0.02 (0.1%) | 1.73 (7.5%) | 0.30 (1.3%) |
| FI whole view | 33.87 s | 0.45 (1.3%) / 1.29 (3.8%) / 0.08 (0.2%) | 0.04 (0.1%) | 0.66 (2.0%) | 18.16 (53.6%) | 3.50 (10.3%) | 0.09 (0.3%) | 2.27 (6.7%) | 0.47 (1.4%) | 0.05 (0.2%) | 6.35 (18.8%) | 0.47 (1.4%) |
| TN LOD0–2 | 21.50 s | 0.31 (1.4%) / 0.41 (1.9%) / 0.00 | 0.02 (0.1%) | 0.57 (2.6%) | 14.07 (65.4%) | 2.90 (13.5%) | 0.05 (0.2%) | 0.78 (3.6%) | 0.26 (1.2%) | 0.04 (0.2%) | 1.85 (8.6%) | 0.25 (1.2%) |
| TN whole view | 30.63 s | 0.31 (1.0%) / 1.39 (4.5%) / 0.04 (0.1%) | 0.04 (0.1%) | 0.70 (2.3%) | 15.91 (52.0%) | 3.06 (10.0%) | 0.06 (0.2%) | 2.10 (6.8%) | 0.38 (1.2%) | 0.07 (0.2%) | 6.21 (20.3%) | 0.38 (1.2%) |
“Base other” is native plus any other base route. Native appears at LOD4–8 in the whole view; legacy-surface and shared-source routes recorded no calls here. Analytic-batch also recorded no calls.
### Route census and halo work
[route-census.csv](route-census.csv) has exact route calls and points, plus expanded CPU time, for every LOD × caller-stage × route and the LOD0–2 / whole-view aggregates. Grid-fill points for LOD0–2 were:
| Strate | Packed scalar | Packed X8 calls / points | Analytic scalar | Total grid points |
|---|---:|---:|---:|---:|
| FI | 10.519 M | 1.044 M / 6.319 M | 0.989 M | 17.827 M |
| TN | 6.639 M | 1.398 M / 8.423 M | 1.548 M | 16.610 M |
Route-census time is exclusive by outer route and stage; composition time remains inside its packed/analytic route. The cost table is a separate, exclusive phase-first view of those same samples. `dispatch_lookup` and `unknown` rows have zero density-call counts by design.
Halo counts are exact; halo CPU is its sampled share of grid fill and overlaps the cost categories above. FI LOD0–2: 1.534 M of 17.827 M points (8.6%), about 1.92 s CPU (8.4%). FI whole view: 2.524 M of 24.439 M (10.3%), about 2.65 s (7.8%). TN LOD0–2: 1.485 M of 16.610 M (8.9%), about 1.89 s (8.8%). TN whole view: 2.382 M of 22.604 M (10.5%), about 2.47 s (8.1%). The run recorded halo points, not a set of coordinates, so exact cross-tile duplicate-coordinate counts are unavailable.
## Closure and sampled hotspots
The grid estimate uses each LOD’s weighted `grid_fill` sample share of direct worker time; the comparison is direct `mc_grid_ms` timing:
| Strate / scope | Sample estimate | Direct grid fill | Closure |
|---|---:|---:|---:|
| FI LOD0–2 | 19.051 s | 19.058 s | 99.96% |
| FI whole view | 23.931 s | 23.903 s | 100.11% |
| TN LOD0–2 | 17.365 s | 17.377 s | 99.93% |
| TN whole view | 20.818 s | 20.848 s | 99.86% |
Every LOD0–2 bin closed within 1.4%. Sparse far bins were noisier (FI LOD7 reached +18%; TN LOD6 reached −17%), while the whole-view totals still closed within 0.15%. Those per-LOD tails are sample variance, not missing work in the target scopes.
Top symbolized PC samples below are expanded-tick shares, grouped by `addr2line` leaf symbol; the `lower_bound` caller resolves into passage spatial-node visitation:
| Sampled function | FI LOD0–2 / whole | TN LOD0–2 / whole |
|---|---:|---:|
| `VF_FieldValueNoise` | 16.6% / 12.8% | 17.0% / 12.9% |
| `std::lower_bound` in `VisitNearestPassageSpatialNode` | 14.2% / 11.4% | 11.5% / 9.2% |
| `ApplyResolvedStratePassageCarves` | 6.5% / 5.6% | 6.9% / 5.9% |
| `VF_FieldLerp` | 6.3% / 4.8% | 6.5% / 4.8% |
## Biggest lever
Passage carving is the largest phase: 65–66% of LOD0–2 CPU and 52–54% of whole-view CPU. A same-world 2× speedup in this phase would save about 7.0–7.6 worker CPU seconds for LOD0–2 and 8.0–9.1 seconds for the whole view: roughly one third of early CPU and one quarter of whole-view CPU. Removing the phase entirely is the measured hard ceiling (52–54% whole view); it is not a realistic target.
## Failed or excluded runs
The first `ITIMER_PROF` attempts (`fi-profile-r1`, `tn-profile-r1`) recorded 1,822 and 1,701 samples, all on the main thread (`lod=255`), and are excluded. All final r12/r13 profiles and compiled-out controls exited successfully; none timed out.
No `--stream-hash` run was made, as required to keep skip behavior. The source diff adds only opt-in profiling tags, counters, and the sampler; generator and meshing formulas were not changed. Hash equality to `90378a5` was therefore not directly measured.