feat(erasure_code): optimize SVE/SVE2 dot product with XOR for coeffi… - #409
Closed
zwtao40 wants to merge 3 commits into
Closed
feat(erasure_code): optimize SVE/SVE2 dot product with XOR for coeffi…#409zwtao40 wants to merge 3 commits into
zwtao40 wants to merge 3 commits into
Conversation
zwtao40
force-pushed
the
dev_erasurecode_aarch64_optimize
branch
5 times, most recently
from
April 30, 2026 08:23
4a2b958 to
26c5be4
Compare
Author
|
Hi @pablodelara, sorry to bother you. This PR has been open for a while and already received an LGTM from @liuqinfei. Could you please help review it or advise who would be the right maintainer to review/merge this change? Thanks! |
pablodelara
reviewed
Jul 15, 2026
| svuint8_t src_hi2 = svlsr_x(predicate_2, src_data2, 4); | ||
| svuint8_t src_lo3 = svand_x(predicate_3, src_data3, mask0f); | ||
| svuint8_t src_hi3 = svlsr_x(predicate_3, src_data3, 4); | ||
| svuint8_t src_lo0, src_hi0, src_lo1, src_hi1, src_lo2, src_hi2, src_lo3, |
Contributor
There was a problem hiding this comment.
These variables need to be initialized here, since they might be used uninitialized in lines 184 to 201.
Author
There was a problem hiding this comment.
Thanks for pointing this out. I initialized all source nibble vectors at declaration to avoid any potential uninitialized use.
added 2 commits
July 16, 2026 17:11
…cient=1 Optimize the GF(2^8) vector dot product implementation for ARM SVE/SVE2 by using direct XOR operations when the encoding coefficient is 1, eliminating unnecessary table lookups. Technical Details: - Add is_dest_coeff_all_one() helper to detect coefficient=1 blocks - Pre-compute coefficient status for each destination vector - For coefficient=1 blocks: use direct XOR (src_data XOR accumulator) - For other coefficients: use traditional nibble-based table lookup - Optimization applied uniformly inside gf_nvect_dot_prod_sve_unrolled() The optimization leverages the property that EC encoding matrices often have coefficient 1 for the first parity block, making XOR operations sufficient instead of full GF multiplication via table lookup. Performance Results: Kunpeng-920 (SVE): +------------------+------------+------------+--------+ | Test Case | Before | After | Speedup| +------------------+------------+------------+--------+ | 10+1 encode | 15 GB/s | 79 GB/s | 5.3x | | 10+1 decode(1) | 15 GB/s | 78 GB/s | 5.2x | | 4+2 encode | 19 GB/s | 23 GB/s | 1.2x | | 4+2 decode(1) | 24 GB/s | 85 GB/s | 3.5x | | 8+3 encode | 13 GB/s | 14 GB/s | 1.1x | | 8+3 decode(1) | 21 GB/s | 77 GB/s | 3.7x | +------------------+------------+------------+--------+ Kunpeng-950 (SVE2): +------------------+------------+------------+--------+ | Test Case | Before | After | Speedup| +------------------+------------+------------+--------+ | 10+1 encode | 13 GB/s | 84 GB/s | 6.5x | | 10+1 decode(1) | 13 GB/s | 84 GB/s | 6.5x | | 4+2 encode | 17 GB/s | 22 GB/s | 1.3x | | 4+2 decode(1) | 24 GB/s | 85 GB/s | 3.5x | | 8+3 encode | 12 GB/s | 14 GB/s | 1.2x | | 8+3 decode(1) | 12 GB/s | 88 GB/s | 7.3x | +------------------+------------+------------+--------+ Measured using erasure_code_perf tool on Huawei Kunpeng platforms. Files modified: - erasure_code/aarch64/gf_nvect_dot_prod_sve.c Signed-off-by: Chenxuqiang <chenxuqiang3@hisilicon.com> Signed-off-by: Enigmo <guotaowei4@huawei.com>
Initialize the source nibble vectors to avoid potential uninitialized use in the table lookup path. Signed-off-by: Chenxuqiang <chenxuqiang3@hisilicon.com> Signed-off-by: Enigmo <guotaowei4@huawei.com>
zwtao40
force-pushed
the
dev_erasurecode_aarch64_optimize
branch
from
July 16, 2026 09:15
41b65aa to
56d4bf3
Compare
pablodelara
reviewed
Jul 21, 2026
pablodelara
left a comment
pablodelara
left a comment
Contributor
There was a problem hiding this comment.
A couple of comments.
Compute source nibbles when the first non-unit coefficient is found and mark lookup table variables as const. Signed-off-by: Chenxuqiang <chenxuqiang3@hisilicon.com> Signed-off-by: Enigmo <guotaowei4@huawei.com>
Contributor
|
This is merged now, thanks! Just FYI, I removed "Files modified" in commit message, as that info is already in the commit itself. Also, I added some missing "const" qualifiers. Thanks! |
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
3 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.
This patch optimizes the GF(2^8) vector dot product implementation for ARM SVE/SVE2 by using direct XOR operations when the encoding coefficient is 1, eliminating unnecessary table lookups.
Background
In erasure coding, the encoding matrix often has coefficient 1 for the first parity block. When the coefficient is 1, the GF multiplication a × 1 = a simplifies to a direct XOR operation, avoiding the overhead of table-based multiplication.
Changes
Optimization Approach:
Added is_dest_coeff_all_one() helper function to detect coefficient=1 blocks at runtime
Pre-compute coefficient status for each destination vector before the main loop
For coefficient=1 blocks: use direct XOR ( src_data XOR accumulator )
For other coefficients: use traditional nibble-based table lookup
Optimization applied uniformly inside gf_nvect_dot_prod_sve_unrolled()
Key Benefits:
Encoding path: first parity block typically has coefficient=1 → uses XOR optimization
Decoding path: coefficient may not be 1 → automatically falls back to table lookup
No separate functions needed for encode/decode paths
Maintains original code structure and API compatibility
Performance Results
Kunpeng-920 (SVE):
+------------------+------------+------------+--------+
| Test Case | Before | After | Speedup|
+------------------+------------+------------+--------+
| 10+1 encode | 15 GB/s | 79 GB/s | 5.3x |
| 10+1 decode(1) | 15 GB/s | 78 GB/s | 5.2x |
| 4+2 encode | 19 GB/s | 23 GB/s | 1.2x |
| 4+2 decode(1) | 24 GB/s | 85 GB/s | 3.5x |
| 8+3 encode | 13 GB/s | 14 GB/s | 1.1x |
| 8+3 decode(1) | 21 GB/s | 77 GB/s | 3.7x |
+------------------+------------+------------+--------+
Kunpeng-950 (SVE2):
+------------------+------------+------------+--------+
| Test Case | Before | After | Speedup|
+------------------+------------+------------+--------+
| 10+1 encode | 13 GB/s | 84 GB/s | 6.5x |
| 10+1 decode(1) | 13 GB/s | 84 GB/s | 6.5x |
| 4+2 encode | 17 GB/s | 22 GB/s | 1.3x |
| 4+2 decode(1) | 24 GB/s | 85 GB/s | 3.5x |
| 8+3 encode | 12 GB/s | 14 GB/s | 1.2x |
| 8+3 decode(1) | 12 GB/s | 88 GB/s | 7.3x |
+------------------+------------+------------+--------+
Measured using erasure_code_perf tool on Huawei Kunpeng platforms.
Files modified: