Benchmark driving the real rack and the real VirtualTracker over 7 recorded
DrussGT fixtures synthesised into an N-enemy melee. Answers "the virtual bullets
are cheap, why not keep fitness for every enemy in parallel?" (the user's idea,
motivated by making kill-stealing target switches free).
BASELINE: exactly 4.0 predict calls per gun per tick (one per power bin) - 52/tick
for the shipped 13-gun rack (TMSelect is compiled out). The task's 56/tick was
the 14-gun figure.
VERDICT: NOT AFFORDABLE. Budget is 13.16 ms/tick (76 ticks/s measured live).
N=1 46% of budget
N=2 94% <- already at the edge
N=4 189%
N=6 274%
Marginal cost ~= 5.9 ms per extra target, linear.
TWO FINDINGS THE PROPOSAL MISSED:
1. `onResult` TRAINING dominates, not predict. Tsetlin's onResult alone is
3.40 ms/tick - ~99.5% of all 13-gun onResult cost - doing ~174k rand() calls
per resolved bullet. Every spawned bullet that resolves triggers it, so it
scales 1:1 with targets. The per-target cost is the Tsetlin training pass.
2. `MaxBullets=8192` is a HARD BLOCKER, not just CPU. Spawn rate is 56*N/tick and
path-metric bullets live until they hit a wall (40-90 ticks). Measured dropped
bullets/tick: N=1 -> 0, N=2 -> ~3, N=4 -> ~180, N=6 -> ~300. At N=6 the ring
wraps every ~24 ticks, so most bullets are silently clobbered and never scored.
A working N=6 pipeline needs MaxBullets ~30k-50k (~4-6 MB, cheap RAM).
ALSO MEASURED: Tsetlin and KNN do NOT cache per tick - they redo the full TM
forward pass / full KNN scan for EACH of the 4 power bins (Tsetlin 1.94 ms/tick
of predict, KNN 0.45). The earlier "tick-only cache" fix never touched the two
most expensive predicts. Pattern and TMSelect do cache fully.
MITIGATIONS (measured predict+spawn at N=6 vs 13.59 ms baseline):
nearest-K=1 only 45% budget
nearest-K=2 95%
rotate every 3 ticks 95%
drop Tsetlin for extras ~68% (INFERRED from Tsetlin's measured 90% share)
Tsetlin is ~90% of the per-target cost, so excluding it from non-primary targets
makes N=6 fit. "Resolve less often" is not a separate lever - resolution IS when
training happens.
ARCHITECTURAL CAVEAT (correctness, not cost - and not priced into the proposal):
the shared-rack topology is broken for this. The guns are global singletons, so
predicting for enemy B ADVANCES/OVERWRITES enemy A's velocity tracker, KNN
feature history and Tsetlin frame window in the SAME instance. Per-enemy fitness
with correct histories therefore requires PER-ENEMY GUN INSTANCES, which is what
this benchmark measured. That multiplies the (already dominant) Tsetlin cost.
CONSEQUENCE FOR THE PLAN: combined with the measured finding that the selector is
negative value and the rack should shrink to a few good guns, this work is much
less valuable than assumed - with a small rack (Pattern's predict is 40us and
fully cached) the cost falls proportionally. Priority lowered accordingly.
Caveat: the host was heavily loaded (load 15/16), so absolute ms carry ~30-50%
noise; min-of-2 and two independent runs agree on the trend, the Tsetlin
dominance, and the ring overflow. No melee fixture exists in the repo, so the
7 enemies are 7 distinct recorded trajectories (stated in the file header).
SirStone
78975a35c4