On Tue, 19 Nov 2024 00:24:04 GMT, Volodymyr Paprotski <vpaprot...@openjdk.org> wrote:
>> Measuring throughput with JMH parameters `-f 1 -i 2 -wi 3 -r 20 -w 30 -p >> algorithm=AES/CBC/NoPadding -p dataSize=30000000 -p provider=SunJCE -p >> keyLength=128 org.openjdk.bench.javax.crypto.full.AESBench` >> >> Before: >> >> Benchmark (algorithm) (dataSize) (keyLength) (provider) >> Mode Cnt Score Error Units >> AESBench.decrypt AES/CBC/NoPadding 30000000 128 SunJCE >> thrpt 2 25.383 ops/s >> AESBench.decrypt2 AES/CBC/NoPadding 30000000 128 SunJCE >> thrpt 2 32.230 ops/s >> AESBench.encrypt AES/CBC/NoPadding 30000000 128 SunJCE >> thrpt 2 20.489 ops/s >> AESBench.encrypt2 AES/CBC/NoPadding 30000000 128 SunJCE >> thrpt 2 21.383 ops/s >> >> >> After: >> >> Benchmark (algorithm) (dataSize) (keyLength) (provider) >> Mode Cnt Score Error Units >> AESBench.decrypt AES/CBC/NoPadding 30000000 128 SunJCE >> thrpt 2 215.144 ops/s >> AESBench.decrypt2 AES/CBC/NoPadding 30000000 128 SunJCE >> thrpt 2 411.265 ops/s >> AESBench.encrypt AES/CBC/NoPadding 30000000 128 SunJCE >> thrpt 2 64.341 ops/s >> AESBench.encrypt2 AES/CBC/NoPadding 30000000 128 SunJCE >> thrpt 2 73.114 ops/s >> >> >> I have not deterministically proven why chunking works: before the change, >> the CBC intrinsic is not being used; and after chunking, it is. There is >> quite a bit of GC activity in the default AESBench, so `encrypt2/decrypt2` >> versions isolate just crypto (see comment below). > > Volodymyr Paprotski has updated the pull request incrementally with one > additional commit since the last revision: > > dont change the dataSize parameter in the benchmark src/java.base/share/classes/com/sun/crypto/provider/CipherBlockChaining.java line 163: > 161: } > 162: processed += > 163: implEncrypt(plain, plainOffset, plainLen, cipher, > cipherOffset); Why do we have plainLen > chunkSize and not plainLen >= chunkSize? A small comment on that would be helpful. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22086#discussion_r1848789465
