perf: reuse delay matrices across FreqResponsePointwise omega points - #170
Merged
jamestjsp merged 1 commit intoAug 26, 2026
Merged
Conversation
The pointwise sweep rebuilt the effective I/O delay matrix inside applyIODelayAtS on every omega point (a []float64 plus a mat.Dense header), making sweep allocations scale linearly with len(omega): 2 allocations per point on delayed systems. The matrices are pure functions of the System, which is not mutated across the sweep, so they are now computed once before the loop (the transfer-function fallback variant lazily, alongside the fallback TF itself) and passed to the unchanged applyIODelayMatrixAtS per-point arithmetic. Bit-identity holds: the same solves run in the same order and every per-point float operation is unchanged — only the allocation source of the delay matrix moved outside the loop. The existing TestFreqResponsePointwise_* pins stay byte-exact, and a new regression test asserts allocations per sweep no longer grow with sweep length (5 per sweep at 10 and at 1000 points, down from 23 and 2003). Co-Authored-By: Claude Mythos 5 <noreply@anthropic.com>
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
2 participants
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.
Summary
FreqResponsePointwise (v1.4.0, #169) rebuilt the effective I/O delay matrix inside
applyIODelayAtSon every omega point — one[]float64plus onemat.Denseheader per point, so sweep allocations scaled linearly withlen(omega)(2 allocs/point on delayed systems). This hoists the delay matrices out of the sweep loop:delaySS := effectiveIODelayMatrix(sys, p, m, true)computed once before the loop for the state-space pathincludeDelayMatrix=false) computed lazily alongside the fallback TF itself, only if a solve ever failsapplyIODelayMatrixAtS) is completely unchangedBit-identity
The delay matrices are pure functions of the
System, which is not mutated across the sweep — computing them once yields byte-identical floats to computing them per point. The same solves run in the same order; only the allocation source moved. All existingTestFreqResponsePointwise_*bit-identity pins pass unchanged (byte-exact vs single-pointFreqResponse).Numbers
testing.AllocsPerRun, 2-state SISO with input delay:New regression test
TestFreqResponsePointwise_AllocsAmortizeAcrossSweepLengthspins that sweep allocations no longer grow with sweep length.Downstream
On adoption (version bump in APC.Exp.AspenAPC-Go), this removes the monorepo's benchgate alloc exemption for
CalculateTuning/path=simplex_pid(the CM2QFO REMOVE-after note inscripts/benchgate/gate.awk): local A/B with areplaceshows the tuning-sweep rows return to the pre-v1.4.0 allocation band with sec/op flat.🤖 Generated with Claude Code