RFR: 8288047: Accelerate Poly1305 on x86_64 using AVX512 instructions [v5]

[Sandhya Viswanathan]

On Mon, 24 Oct 2022 22:09:29 GMT, vpaprotsk <duke at openjdk.org> wrote:

>> Handcrafted x86_64 asm for Poly1305. Main optimization is to process 16 message blocks at a time. For more details, left a lot of comments in `macroAssembler_x86_poly.cpp`.
>> 
>> - Added new KAT test for Poly1305 and a fuzz test to compare intrinsic and java.
>>   - Would like to add an `InvalidKeyException` in `Poly1305.java` (see commented out block in that file), but that conflicts with the KAT. I do think we should detect (R==0 || S ==0) so would like advice please.
>> - Added a JMH perf test.
>>    - JMH test had to use reflection (instead of existing `MacBench.java`), since Poly1305 is not 'properly' registered with the provider.
>> 
>> Perf before:
>> 
>> Benchmark                   (dataSize)  (provider)   Mode  Cnt        Score        Error  Units
>> Poly1305DigestBench.digest          64              thrpt    8  2961300.661 ± 110554.162  ops/s
>> Poly1305DigestBench.digest         256              thrpt    8  1791912.962 ±  86696.037  ops/s
>> Poly1305DigestBench.digest        1024              thrpt    8   637413.054 ±  14074.655  ops/s
>> Poly1305DigestBench.digest       16384              thrpt    8    48762.991 ±    390.921  ops/s
>> Poly1305DigestBench.digest     1048576              thrpt    8      769.872 ±      1.402  ops/s
>> 
>> and after:
>> 
>> Benchmark                   (dataSize)  (provider)   Mode  Cnt        Score        Error  Units
>> Poly1305DigestBench.digest          64              thrpt    8  2841243.668 ± 154528.057  ops/s
>> Poly1305DigestBench.digest         256              thrpt    8  1662003.873 ±  95253.445  ops/s
>> Poly1305DigestBench.digest        1024              thrpt    8  1770028.718 ± 100847.766  ops/s
>> Poly1305DigestBench.digest       16384              thrpt    8   765547.287 ±  25883.825  ops/s
>> Poly1305DigestBench.digest     1048576              thrpt    8    14508.458 ±     56.147  ops/s
>
> vpaprotsk has updated the pull request incrementally with one additional commit since the last revision:
> 
>   extra whitespace character

src/hotspot/cpu/x86/assembler_x86.cpp line 8306:

> 8304:   assert(dst != xnoreg, "sanity");
> 8305:   InstructionMark im(this);
> 8306:   InstructionAttr attributes(vector_len, /* vex_w */ true, /* legacy_mode */ false, /* no_mask_reg */ false, /* uses_vl */ true);

no_mask_reg should be set to true here as we are not setting the mask register here.

src/hotspot/cpu/x86/stubRoutines_x86.cpp line 83:

> 81: address StubRoutines::x86::_join_2_3_base64 = NULL;
> 82: address StubRoutines::x86::_decoding_table_base64 = NULL;
> 83: address StubRoutines::x86::_poly1305_mask_addr = NULL;

Please also update the copyright year to 2022 for stubRoutines_x86.cpp and hpp files.

src/hotspot/cpu/x86/vm_version_x86.cpp line 925:

> 923:     _features &= ~CPU_AVX512_VBMI2;
> 924:     _features &= ~CPU_AVX512_BITALG;
> 925:     _features &= ~CPU_AVX512_IFMA;

This should also be done under is_knights_family().

src/java.base/share/classes/com/sun/crypto/provider/Poly1305.java line 175:

> 173:             // Choice of 1024 is arbitrary, need enough data blocks to amortize conversion overhead
> 174:             // and not affect platforms without intrinsic support
> 175:             int blockMultipleLength = (len/BLOCK_LENGTH) * BLOCK_LENGTH;

The ByteBuffer version can also benefit from this optimization if it has array as backing storage.

-------------

PR: https://git.openjdk.org/jdk/pull/10582