Felix-Gong opened a new pull request, #3601: URL: https://github.com/apache/brpc/pull/3601
### Summary Follow-up to #3571 (which rewrote `rv_crc32c_vclmul`). `PR3332` made the RISC-V dispatch select the **Zvbc vector path first** whenever the CPU reports Zvbc. With the raw PR3332 implementation, per-iteration scalar round-trips made the vector fold **slower than the scalar Zbc core** (0.28× at 64 B … 0.32× at 1 MiB on X100), so vector-first selection was a performance regression for exactly the CPUs already accelerated by PR3312. This PR **swaps the dispatch order** in `Choose_Extend()`: - **Scalar Zbc preferred** when available; - **Zvbc vector path only as a fallback** on cores with no scalar Zbc (e.g. SG2044-class); - Scalar-first also naturally keeps small buffers (<256 B) on the faster scalar path, where vector setup/merge overhead exceeds its gains. No behavior change on non-RISC-V builds or cores without Zbc/Zvbc (software table fallback stays). ### Performance k3 (X100, Zbc+Zvbc, VLEN=256, warmup 10 + 100-round median, same harness as PR3312): | size | vclmul-over-clmul (with vector-first) | dispatch after this PR | |------|---------------------------------------|------------------------| | 64 B | 0.45× (regression) | clmul (scalar) | | 256 B | 1.56× | clmul (scalar) | | 1 MiB | 7.46× | clmul (scalar) | The scalar core is selected at all sizes; `vclmul` remains the fallback for Zvbc-only cores. (The full-width vector path from #3571 can outpace clmul at ≥256 B, and would justify vector selection on cores *without* scalar Zbc.) ### Test plan - [x] Full `test_butil` build (`-DWITH_RISCV_ZVBC=ON -DBUILD_UNIT_TESTS=ON`) - [x] Official `CRC.*` gtest suite 5/5 PASSED (clmul path exercised via dispatch) - [x] RFC vectors + boundary combos bit-consistent - [ ] VLEN=128 (SG2044-class) hardware run — pending platform access -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
