AES ctr benchmark performance

[Adam Petcher]

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
>>
>