Skip to content

Reduce state-copy pressure in the hottest SILK mode - #503

Open
lpi wants to merge 1 commit into
xiph:mainfrom
lpi:main
Open

lpi wants to merge 1 commit into
xiph:mainfrom
lpi:main

Conversation

@lpi

@lpi lpi commented Sep 16, 2026

Copy link
Copy Markdown

Complexity-10 AArch64 NEON encoding with four delayed-decision states repeatedly copies one narrow state lane across the state rows. Preserve every fallback and state transition while scheduling that exact copy four rows at a time.

On an m4 mac processor this increases transcoding speed by 8%, on a aws c8g graviton, about 4%.

Complexity-10 AArch64 NEON encoding with four delayed-decision states repeatedly copies one narrow state lane across the state rows. Preserve every fallback and state transition while scheduling that exact copy four rows at a time.

Constraint: Owner authorized prior valid research performance evidence after the exact-production campaign remained invalid and ungraded
Rejected: Import the research commit | it contains experiments, diagnostics, and unrelated candidates
Confidence: high
Scope-risk: narrow
Directive: Keep the four-row 32-bit schedule and scalar remainder bound to c10/four-state AArch64 code generation
Tested: Exact local and Graviton premeasurement differentials; OPUS_CHECK_ASM; ASan/UBSan; CMake/autotools/Meson; AArch64 codegen; Kimi K3 PASS
Not-tested: Fresh exact-production performance did not complete; prior qualified research performance was used by explicit owner decision
@lpi lpi changed the title Reduce state-copy pressure in the hottest SILK mode (#1) Reduce state-copy pressure in the hottest SILK mode Sep 16, 2026
@lpi

lpi commented Sep 16, 2026

Copy link
Copy Markdown
Author

I tested this, output is exactly the same across many different files.

@lpi

lpi commented Sep 16, 2026

Copy link
Copy Markdown
Author

Tested head: c97fd0b1d10fd59e5b1610e82fae8bfeae7801a9.

The earlier directly qualified Graviton4 comparison against stock found the useful Candidate-3 result: production c10 encode improved thread CPU by +4.0713% and wall by +4.0826%, with c10 p99.9 +4.7248% and an optimized-symbol diagnostic of +17.3194%. Positive percentages mean faster/lower cost. The c5/c9 controls were approximately zero. This used 28 blocks and 22,400 frames per label per preset, with exact packet, final-range, and output identity. This remains the benchmark baseline.

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