On Thu, 22 Oct 2026 17:45:04 GMT, Volodymyr Paprotski <[email protected]>
wrote:
>> I added an AVX2 version of AES/CTR intrinsic. Rather then adding a third
>> version of that intrinsic (we already have an AVX512 and an AES128), I
>> refactored existing ones so I could parametrize just one intrinsic. AVX512
>> got better at small payloads and AVX128 got better at large payloads. And
>> ECore/AVX256 used to use fall back to 128, now it doesn't.
>>
>> | Benchmark | Data | Key | AVX128 | AVX256 | AVX512 |
>> |---|---|---|---|---|---|
>> | AESBench.encrypt | 16 | 128 | 0% | 5% | 92% |
>> | AESBench.encrypt | 32 | 128 | 0% | 1% | 37% |
>> | AESBench.encrypt | 64 | 128 | 23% | 33% | 30% |
>> | AESBench.encrypt | 128 | 128 | 6% | 1% | 35% |
>> | AESBench.encrypt | 256 | 128 | 26% | 16% | 4% |
>> | AESBench.encrypt | 1024 | 128 | 29% | 13% | 0% |
>> | AESBench.encrypt | 16384 | 128 | 24% | 13% | 7% |
>> | AESBench.encrypt | 16 | 192 | 3% | 5% | 69% |
>> | AESBench.encrypt | 32 | 192 | 1% | 4% | 39% |
>> | AESBench.encrypt | 64 | 192 | 30% | 42% | 30% |
>> | AESBench.encrypt | 128 | 192 | 12% | 13% | 30% |
>> | AESBench.encrypt | 256 | 192 | 32% | 19% | 6% |
>> | AESBench.encrypt | 1024 | 192 | 25% | 15% | 1% |
>> | AESBench.encrypt | 16384 | 192 | 20% | 12% | 8% |
>> | AESBench.encrypt | 16 | 256 | -1% | 4% | 62% |
>> | AESBench.encrypt | 32 | 256 | 2% | 5% | 31% |
>> | AESBench.encrypt | 64 | 256 | 31% | 67% | 18% |
>> | AESBench.encrypt | 128 | 256 | 13% | 16% | 29% |
>> | AESBench.encrypt | 256 | 256 | 33% | 18% | 4% |
>> | AESBench.encrypt | 1024 | 256 | 23% | 15% | -2% |
>> | AESBench.encrypt | 16384 | 256 | 19% | 13% | 9% |
>>
>> Just note, measuring exact performance with our current AESBench JMH, and
>> especially at small payloads, can be an exercise in frustration. The
>> benchmark constantly allocates the result and discards it, producing a lot
>> of GC. (While developing, I instrumented the code to call the intrinsic
>> directly, but that involved making many methods public.. so not something
>> that can be checked in.)
>>
>> This is the invocation that gave me the most stable/repeatable results
>> (still swings on reruns, but not as much.. a very long run however).
>>
>>
>> HEAP="-Xms4g -Xmx4g"
>> JMH="-f 3 -i 10 -r 3 -wi 5 -w 5"
>> NEW=./build/linux-x86_64-server-release
>> BASE=./build/base
>> BENCH=org.openjdk.bench.javax.crypto.full.AESBench
>> SIZES="16 32 64 128 256 1024 16384"
>> ARGS="-p algorithm=AES/CTR/NoPadding"
>> for size in $SIZES; do
>> $NEW/images/jdk/bin/java -jar $NEW/images/test/micro/benchmarks.jar
>> $JMH -jvmArgsAppend "$HEAP" $ARGS -p dataSize=$size $BENCH 2>&1 | te...
>
> Volodymyr Paprotski has updated the pull request incrementally with one
> additional commit since the last revision:
>
> add back the AOT recording
src/hotspot/cpu/x86/stubGenerator_x86_64_aes.cpp line 313:
> 311: if (dst != nds) {
> 312: movdqu(dst, nds);
> 313: }
May be an assert here that dst != src?
src/hotspot/cpu/x86/stubGenerator_x86_64_aes.cpp line 325:
> 323: if (dst != nds) {
> 324: movdqu(dst, nds);
> 325: }
May be an assert here that dst != src?
src/hotspot/cpu/x86/stubGenerator_x86_64_aes.cpp line 337:
> 335: if (dst != nds) {
> 336: movdqu(dst, nds);
> 337: }
May be an assert here that dst != src?
src/hotspot/cpu/x86/stubGenerator_x86_64_aes.cpp line 364:
> 362: if (dst != nds) {
> 363: movdqu(dst, nds);
> 364: }
May be an assert here that dst != src?
src/hotspot/cpu/x86/stubGenerator_x86_64_aes.cpp line 955:
> 953: vector_len = Assembler::AVX_256bit;
> 954: } else {
> 955: assert(VM_Version::supports_vaes() || (VM_Version::supports_aes()
> && VM_Version::supports_sse4_1()), "AESNI intrinsic unsupported");
Do we need VM_Version::supports_vaes() here?
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/33128#discussion_r4449351048
PR Review Comment: https://git.openjdk.org/jdk/pull/33128#discussion_r4449356859
PR Review Comment: https://git.openjdk.org/jdk/pull/33128#discussion_r4449360030
PR Review Comment: https://git.openjdk.org/jdk/pull/33128#discussion_r4449364724
PR Review Comment: https://git.openjdk.org/jdk/pull/33128#discussion_r4449124030
