AES ctr benchmark performance
Adam Petcher
adam.petcher at oracle.com
Tue Dec 4 18:40:47 UTC 2018
Another thing I noticed: The AES microbenchmark tests the performance of
Cipher.doFinal(byte[]), which allocates an array on each call. This is
(arguably) a bug in the benchmark, so I created JDK-8214800 to track it.
Based on my experiments, this bug accounts for around 30% of the
difference between OpenSSL performance and the JDK performance, as
reported by this benchmark.
On 12/3/2018 5:30 PM, Adam Petcher wrote:
> I'm seeing JDK 11 performance around 40% of OpenSSL performance, too.
> This is on a Core i7-4980HQ (Haswell, turbo at 4 GHz).
>
> In addition to the "Java stuff" (e.g. garbage collection, array bounds
> checking) that Tony suggested, there is also the issue that the JDK
> native implementation does not interleave instructions, but the
> OpenSSL implementation does. The OpenSSL source file[1] has some great
> information about the effect of interleaving and the performance on
> various platforms. The JDK implementation of AES-CTR encrypts 6 blocks
> at a time, but it does all the other operations (increment counter,
> xor, etc) in sequence with the aesenc operations. The OpenSSL
> implementation performs all of these other operations in parallel with
> the aesenc operations. This difference in the native implementation
> likely accounts for some of the difference in performance, but I don't
> know how much. The "other" operations only require a relatively small
> number of cycles, but doing them in sequence may hurt performance a
> lot due to pipeline stalls.
>
> [1]
> https://github.com/openssl/openssl/blob/master/crypto/aes/asm/aesni-x86_64.pl
>
> On 12/3/2018 1:45 PM, Anthony Scarpino wrote:
>> Hi,
>>
>> That is how I read it, but when I've done the test it's closer to
>> 55%. But openssl speed and jmh are not comparable. Openssl is only
>> running through it's algorithm, while jmh is running through the VM
>> and java byte code. jmh has to do more work outside of pure crypto
>> ops than openssl.
>>
>> Tony
>>
>>
>> On 12/3/18 12:09 AM, Kasper Janssens wrote:
>>> Hello,
>>>
>>> I've been measuring the performance of the java 11 built in AES-NI
>>> instructions and, with NI switched on through JAVA_TOOL_OPTIONS =
>>> ‘-XX:+UnlockDiagnosticVMOptions -XX:+UseAES -XX:+UseAESIntrinsics’.
>>>
>>> I run the benchmarks that are present in the open jdk itself
>>> through ‘java -server -jar
>>> target/jmh-jdk-microbenchmarks-1.0-SNAPSHOT.jar
>>> org.openjdk.bench.javax.crypto.full.AESBench.encrypt -p
>>> algorithm=AES/CTR/NoPadding’.
>>>
>>> When I compare the results and calculate the throughput in GB/s, for
>>> 16k encoding blocks, I get about 40% of the throughput when compared
>>> to the openssl performance test through ‘openssl speed -evp
>>> aes-128-ctr’.
>>>
>>> I don't seem to find a decent comparison/benchmark that describes
>>> which percentage of the maximum performance to expect with jdk 11,
>>> but 40 % seems rather low. Does anybody know of a comparison (or
>>> might have an idea where I go wrong, because, as these are off the
>>> shelf perf tools I would think not a lot can be tweaked there).
>>>
>>> For reference, the openssl test reports this:
>>>
>>> The 'numbers' are in 1000s of bytes per second processed.
>>>
>>> type 16 bytes 64 bytes 256 bytes 1024 bytes
>>> 8192 bytes 16384 bytes
>>>
>>> aes-128-ctr 583576.76k 1907072.21k 4144141.40k 5612174.68k
>>> 6252751.53k 6258371.24k
>>>
>>> So, for 16k blocks, 6258371k bytes per second
>>>
>>> The openjdk benchmark reports this
>>>
>>> Benchmark (algorithm) (dataSize) (keyLength)
>>> (provider) Mode Cnt Score Error Units
>>>
>>> AESBench.encrypt AES/CTR/NoPadding 16384 128
>>> thrpt 100 168066.873 ± 488.873 ops/s
>>>
>>> Out of which I conclude that, for 16k blocks, the perf here is
>>> 168066 * 16k or about 2689056k bytes per second or about 40 % of the
>>> openssl number, taking some liberty with rounding the numbers.
>>>
>>> Is that expected or am I drawing the wrong conclusions? Or am I
>>> missing something?
>>>
>>> When I print the options, the jvm reports that the AES intrinsics
>>> are being used :
>>>
>>> java -XX:+PrintFlagsFinal | grep -i AES
>>>
>>> intx MaxBCEAEstimateLevel =
>>> 5 {product} {default}
>>>
>>> intx MaxBCEAEstimateSize =
>>> 150 {product} {default}
>>>
>>> bool UseAES =
>>> true {product} {default}
>>>
>>> System specs : Ubuntu 18.04
>>>
>>> openjdk version "10.0.2" 2018-07-17
>>>
>>> OpenJDK Runtime Environment (build 10.0.2+13-Ubuntu-1ubuntu0.18.04.4)
>>>
>>> OpenJDK 64-Bit Server VM (build 10.0.2+13-Ubuntu-1ubuntu0.18.04.4,
>>> mixed mode)
>>>
>>> Kasper
>>>
>>
More information about the security-dev
mailing list