Skip to content

Swept the stack-heavy measurement across placements, and qualified its result - #638

Merged
fdesbiens merged 1 commit into
eclipse-threadx:devfrom
fdesbiens:feature/r52-s32z280-sweep-deep-stack
Aug 18, 2026
Merged

Swept the stack-heavy measurement across placements, and qualified its result#638
fdesbiens merged 1 commit into
eclipse-threadx:devfrom
fdesbiens:feature/r52-s32z280-sweep-deep-stack

Conversation

@fdesbiens

Copy link
Copy Markdown
Contributor

#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:

placement BTCM min / spread DRAM0 min / spread
offset 0 41,854 / 6,850 42,036 / 6,880
offset 16 48,670 / 1,946 48,792 / 1,978
offset 32 42,388 / 6,914 42,752 / 7,018
offset 48 48,914 / 1,860 49,198 / 6,786

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.

…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>
@fdesbiens
fdesbiens merged commit ca62edd into eclipse-threadx:dev Aug 18, 2026
4 checks passed
@fdesbiens
fdesbiens deleted the feature/r52-s32z280-sweep-deep-stack branch August 18, 2026 12:51
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant