AES ctr benchmark performance

[Kasper Janssens]

Thanks for the answer! It’s good to know that I am likely not missing something. Okay, so I reckon that a large part of the extra work is copying buffers from the VM to get used by the AES instructions on the chip? 

On 03/12/2018, 19:47, "Anthony Scarpino" <anthony.scarpino at oracle.com> 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
    >