> 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 | tee -a > new.log > $BASE/images/jdk/bin/java -jar $BASE/images/test/micro/benchma...
Volodymyr Paprotski has updated the pull request incrementally with one additional commit since the last revision: add back the AOT recording ------------- Changes: - all: https://git.openjdk.org/jdk/pull/33128/files - new: https://git.openjdk.org/jdk/pull/33128/files/a94034d4..50642896 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=33128&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=33128&range=00-01 Stats: 13 lines in 1 file changed: 11 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/33128.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/33128/head:pull/33128 PR: https://git.openjdk.org/jdk/pull/33128
