zerocheck: EOR3 fold in the URM convert loops (about 1.06-1.10x on the kernel)#15
Open
gopikannappan wants to merge 1 commit into
Open
zerocheck: EOR3 fold in the URM convert loops (about 1.06-1.10x on the kernel)#15gopikannappan wants to merge 1 commit into
gopikannappan wants to merge 1 commit into
Conversation
On chips with FEAT_SHA3 (Apple M-series, ARMv8.2+ with SHA3), fold two convert-table lookups per step into the accumulator with a single 3-input veor3q_u8 instead of two veorq_u8, halving the XOR instruction count in the dense convert loops of both round1 URM paths. XOR is associative so the result is bit-identical; the urm_probe checksum and all 35 kernel tests are unchanged. Gated on target_feature sha3 with the original veorq loop as fallback, so non-SHA3 aarch64 (for example Graviton2) compiles and runs the old path. Measured on the isolated URM kernel (urm_probe, m=29, single thread, best of 12 runs, A/B binaries alternated in the same thermal window): Apple M2: 172 to 156 ms per call, about 1.10x. Apple M4: 36.0 to 33.9 ms per call, about 1.06x. Folding the shift_reduce accumulator XORs the same way was measured slightly slower (that path is load-bound, not XOR-chain-bound), so this change touches only the convert loops. Co-Authored-By: Claude Fable 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
1 participant
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.
On chips with FEAT_SHA3 (Apple M series, ARMv8.2+ with the SHA3 extension), the dense convert-accumulate loops in both round1 URM paths can fold two table lookups per step with a single 3-input veor3q_u8 instead of two veorq_u8. XOR is associative, so the result is bit identical: the urm_probe checksum is unchanged and all 35 kernel tests pass on both the EOR3 path and the fallback.
Measured on the isolated URM kernel (urm_probe, m=29, single thread, best of 12 runs, with base and patched binaries alternated in the same thermal window):
The change is gated on target_feature sha3, with the original veorq loop kept as the fallback, so aarch64 chips without SHA3 (Graviton2 for example) compile and run the old path. Both configurations were compile- and test-checked (RUSTFLAGS with target-feature=-sha3 for the fallback).
Two notes from the exploration: folding the shift_reduce accumulator XORs the same way measured slightly slower (that path is load-bound rather than XOR-chain-bound), so only the convert loops are touched. And since the M4 Max also has FEAT_SHA3, the benchmark reference machine should see the gain too.
Happy to adjust gating style or run more configurations if useful.
Context: found while building an XMSS signature aggregator on top of Flock (https://github.com/gopikannappan/flock-xmss), the "signature aggregation would require additional work" direction from the paper.