HADOOP-19724. [RISC-V] Add rv64 Zbc (CLMUL) bulk CRC32 (CRC32C not optimized) #8031
Conversation
…etection Co-authored-by: gong-flying <[email protected]>
|
💔 -1 overall
This message was automatically generated. |
|
@steveloughran could you please review this PR if you have time? thanks! |
|
Hi @pan3793 @slfan1989 , could you please take a look when you have a moment? Happy to address any feedback. Thanks! |
|
Is everyone with a risc-v setup able to test this? |
@PeterPtroc Thank you for your contribution! However, RISC-V is beyond my current knowledge, and I’m sorry I’m unable to assist with reviewing this part of the code. I recommend reaching out to other team members for assistance with the review. |
to reviewers, #7924 may help you to set up a dev box on x86 or aarch platform by leveraging Docker & QEMU to simulate riscv env, but it's super super slow, either has no means of performance evaluation. |
steveloughran
left a comment
steveloughran
left a comment
There was a problem hiding this comment.
ok, I've tried to review this and asked google gemini to look at specific aspects (alignment, assembly, pointer). It's happy "Yes, the RISC-V assembly code in this pull request looks excellent. It is correct, safe, and follows modern best practices for inline assembly.". If I hadn't been arguing with it and latex citations all afternoon I'd treat its opinions as valid. But here they are as good as my judgement.
I propose adding a comment on each method so that whoever reads this code next understands what it tries to do. Same for the processing of the misaligned data at the start of an operation, and any leftovers.
that's all: explain things for future developers.
+1 pending these changes
| return rv_crc32_zlib_bitwise(crc, p, n); | ||
| } | ||
|
|
||
| uintptr_t mis = (uintptr_t)p & 0xF; |
There was a problem hiding this comment.
comment that this is to handle misaligned data and that this is considered unlikely
|
|
||
| #if defined(__riscv) && (__riscv_xlen == 64) | ||
|
|
||
| #define RV_CRC32_CONST_R3 0x01751997d0ULL |
There was a problem hiding this comment.
explain what these are...assumign they're all defined in the crc spec, say so
| #define RV_CRC32_POLY_TRUE_LE_FULL 0x01DB710641ULL | ||
| #define RV_CRC32_CONST_RU 0x01F7011641ULL | ||
|
|
||
| static inline uint64_t rv_clmul(uint64_t a, uint64_t b) { |
There was a problem hiding this comment.
explain what it does with a comment. same for the methods below
| const uint64_t C1 = RV_CRC32_CONST_R3; | ||
| const uint64_t C2 = RV_CRC32_CONST_R4; | ||
|
|
||
| while (likely(n >= 16)) { |
There was a problem hiding this comment.
and explain this is going through 16 bytes of aligned data
| * p_buf : The base address of the data buffer. The buffer should be | ||
| * at least as big as block_size * num_blocks. | ||
| * block_size : The size of each block in bytes. | ||
| * num_blocks : The number of blocks to work on. Min = 1, Max = 3 |
There was a problem hiding this comment.
0 is taken too, just treated as a no-op. mention and that any other value raises an assertion. which isn't going to be picked up, is it?
6 participants
Description of PR
Below are the performance changes observed using the built-in CRC32 benchmark. Although performance is poor when bpc <= 64, there are substantial improvements when bpc > 64. To keep the codebase simple and maintainable, I did not add bpc-size-specific handling.
How was this patch tested?
Built hadoop-common with native profile on riscv64; verified it's function by TestNativeCrc32.
Ran Hadoop’s CRC32 benchmark on riscv64 (OpenEuler/EulixOS) with JDK 17.
Here is the commands and results:
Command：
Results
Command：
Results (Origin)
Results (With this commit)
For code changes:
LICENSE,LICENSE-binary,NOTICE-binaryfiles?