Swept the stack-heavy measurement across placements, and qualified its result - #638
Merged
fdesbiens merged 1 commit intoAug 18, 2026
Conversation
…s result eclipse-threadx#636 reported that a stack in BTCM gave a threefold tighter spread than DRAM0 for stack-heavy work. That measurement used a single code placement, which is the methodology eclipse-threadx#631 and eclipse-threadx#633 exist to correct: the cache benchmark got an alignment sweep and the interrupt handler got one, and this measurement never did. It was noticed when eclipse-threadx#637 added two threads to the same image and the figure moved -- both spreads came out near 6500 and the minima rose 15%. The recursive body is now generated at four placements and all four are measured, per placement, in one image. placement BTCM min / spread DRAM0 min / spread offset 0 41854 / 6850 42036 / 6880 offset 16 48670 / 1946 48792 / 1978 offset 32 42388 / 6914 42752 / 7018 offset 48 48914 / 1860 49198 / 6786 Reproducible across runs to within a few hundred cycles. Spread is dominated by code placement rather than by the memory holding the stack. It ranges from 1860 to 6914 depending on where the body falls in a cache line, and placement also moves the minimum by 17%, from 41854 to 49214. Against that, the memory contributes a consistent but small advantage: BTCM's minimum is lower at all four placements, by 0.4% to 0.9%. BTCM's spread beats DRAM0's decisively at one placement of the four, offset 48, at 1860 against 6786. At the other three the two are within 2% of each other. So the effect eclipse-threadx#636 reported is real where it occurs and is not a property of the part: quoting it as one invited the reader to expect it everywhere. eclipse-threadx#636's claim should be read as qualified by this. A stack in BTCM buys a small consistent improvement in the best case and a large improvement in spread at some code placements and not others. Anyone building a determinism argument on it needs the placement sweep in the loop, not a single figure. The pad nops that displace each placement execute on every recursion level rather than once, so each placement carries a slightly different constant cost, about 0.6% at the widest. That cancels in the BTCM against DRAM0 comparison, which is made at the same placement, and does not affect spread within one. Assisted-by: Claude Code (Opus 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
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.
#636 reported that a stack in BTCM gave a 3.4× tighter spread than DRAM0 for stack-heavy work. That measurement used a single code placement — the exact methodology #631 and #633 exist to correct. The cache benchmark got an alignment sweep and the interrupt handler got one; this measurement never did.
It surfaced when #637 added two threads to the same image and the figure moved: both spreads came out near 6,500 and the minima rose 15%.
Swept
The recursive body is now generated at four placements, all four measured per placement in one image:
Reproducible across runs to within a few hundred cycles.
What it means
Spread is dominated by code placement, not by the memory holding the stack. It ranges 1,860 to 6,914 depending on where the body falls in a cache line, and placement moves the minimum by 17% (41,854 to 49,214).
Against that, the memory contributes a small but consistent advantage: BTCM's minimum is lower at all four placements, by 0.4% to 0.9%.
BTCM's spread beats DRAM0's decisively at one placement of four — offset 48, 1,860 against 6,786. At the other three they are within 2% of each other.
#636 should be read as qualified by this
The effect it reported is real where it occurs but is not a property of the part. Quoting it as one invited the reader to expect it everywhere. A stack in BTCM buys a small consistent improvement in the best case, and a large improvement in spread at some code placements and not others. Anyone building a determinism argument on it needs the placement sweep in the loop, not a single figure.
Method note
The pad nops that displace each placement execute on every recursion level rather than once, so each placement carries a slightly different constant cost — about 0.6% at the widest pad. That cancels in the BTCM-against-DRAM0 comparison, which is made at the same placement, and does not affect spread within a placement.