Optimize crc64_rocksoft for aarch64

[tipabu]

Closes #326

[pablodelara]

Hi @tipabu. What do you mean with this phrase? "I'm not how worried to be about them." It looks like this needs some rewording, thanks.

[tipabu]

Fixed up -- sorry about that! Was just missing a "sure":

I'm not sure how worried to be about them.

[tipabu]

FWIW, running locally (M4 MacBook Air) with master I see results like

crc64_rocksoft_norm_perf:
Start timed tests
crc64_rocksoft_norm_warm: runtime =    3062418 usecs, bandwidth 1516 MB in 3.0624 sec = 495.03 MB/s
finish 0xdd347d865410fc77
crc64_rocksoft_refl_perf:
Start timed tests
crc64_rocksoft_refl_warm: runtime =    3062684 usecs, bandwidth 1666 MB in 3.0627 sec = 544.28 MB/s
finish 0x8a0da75d679587c2

vs

crc64_rocksoft_norm_perf:
Start timed tests
crc64_rocksoft_norm_warm: runtime =    3062542 usecs, bandwidth 104695 MB in 3.0625 sec = 34185.81 MB/s
finish 0xdd347d865410fc77
crc64_rocksoft_refl_perf:
Start timed tests
crc64_rocksoft_refl_warm: runtime =    3017980 usecs, bandwidth 107434 MB in 3.0180 sec = 35598.00 MB/s
finish 0x8a0da75d679587c2

with this. Also did some extra equivalency testing against the base implementation with https://paste.opendev.org/show/bG3ZmKo1m1D2MZqb7B8Q/

[pablodelara]

Thanks @tipabu. Could you also update Release notes with this change?

[tipabu]

Should it go under 2. FIXED ISSUES or 3. CHANGE LOG & FEATURES ADDED? I'm thinking something like

* CRC64 Rocksoft implementation on aarch64 optimized similar to other CRC64 implementations.

[jeffareid]

Is someone going to add the rock soft polynomial to the X86 code base?

[tipabu]

It's already there and optimized (see crc/crc64_rocksoft_*.asm) -- in fact, the x86_64 assembly is where I went for the constants for p4, p1, p0, and br.

[jeffareid]

It's already there

Somehow I missed that. Is there a program to generate the rk constants used in the .asm files. similar to what I did when I ported an older version to build with Visual Studio, such as crc64fg.cpp or crc64rg.cpp ?

[pablodelara]

Should it go under 2. FIXED ISSUES or 3. CHANGE LOG & FEATURES ADDED? I'm thinking something like

* CRC64 Rocksoft implementation on aarch64 optimized similar to other CRC64 implementations.

Under 3. CHANGE LOG..., in the v2.32 section. Thanks!

[pablodelara]

Should it go under 2. FIXED ISSUES or 3. CHANGE LOG & FEATURES ADDED? I'm thinking something like

* CRC64 Rocksoft implementation on aarch64 optimized similar to other CRC64 implementations.

Under 3. CHANGE LOG..., in the v2.32 section. Thanks!

Don't forget to rebase :)

[tipabu]

@jeffareid Your same programs work; just need to #define rk08 0xad93d23594c93659ull // crc64 rocksoft -- though there's a difference of 1 in the rk8 / br_high values. This is similar to the discrepancy noted in 77d76b6... With some random testing, though, I couldn't find an input where that led to a difference in checksum.

@pablodelara Done.

[jeffareid]

@tipabu

there's a difference of 1 in the rk8 / br_high values. This is similar to the discrepancy noted in 77d76b6... With some random testing, though, I couldn't find an input where that led to a difference in checksum.

That difference of 1 only occurs with refl CRC, and there is no advantage to not have the right most bit of rk8 set to 1. For reflected CRC, rk8 = the right most 64 bits of a 65 bit reversed polynomial. The missing 65th bit represents x^0, while the right most bit in rk8 represents x^64. Since the CRC is 64 bits, that right most x^64 bit can be ignored (set to 0), but there is no advantage to not having it set to 1.

If interested, I can explain this in more detail.

[tipabu]

Thanks for the detailed explanation, @jeffareid! I think it finally clicked for me with

Since only the bits corresponding to x^0 to x^63 of the result are used for CRC, the calculation for bits corresponding to x^64 to x^127 is not fully implemented, which is why that right most bit (x^64) of rk8 can be 0 or 1, as it's not used.

[jeffareid]

@tipabu

Thanks for the detailed explanation, @jeffareid! I think it finally clicked for me with

Since only the bits corresponding to x^0 to x^63 of the result are used for CRC, the calculation for bits corresponding to x^64 to x^127 is not fully implemented, which is why that right most bit (x^64) of rk8 can be 0 or 1, as it's not used.

If fully implemented, then the bits for x^64 to x^127 will all end up equal to zero, but that calculation is not needed since the returned CRC is only for x^0 to x^63. Still there's no advantage of leaving out the x^64 bit in rk8, so I don't know why that was done.