AES ctr benchmark performance

[Bernd Eckenfels]

Well yes, was just wondering why the options had to be enabled explicitely and why -XX:+UnlockDiagnosticVMOptions was used. But I guess that was just unrelated info.

BTW: does the C2 warmup Problem strike here again maybe?

Gruss
Bernd
-- 
http://bernd.eckenfels.net

Von: Anthony Scarpino
Gesendet: Montag, 3. Dezember 2018 21:37
An: Bernd Eckenfels; security-dev at openjdk.java.net
Betreff: Re: AES ctr benchmark performance

Very slow..  Roughly 181k ops/sec vs 6100 ops/sec, for 16k datasize.

As far as why there is a switch, mostly debugging or possible bugs in 
hotspot that cause the intrinsic to break.

Tony

On 12/3/18 12:27 PM, Bernd Eckenfels wrote:
> Quick Question, why did you Need to switch it on and out of curiosity 
> how do the times look like when you switch NI off?
> 
> Greetings
> 
> Bernd
> 
> -- 
> http://bernd.eckenfels.net
> 
> *Von: *Anthony Scarpino <mailto:anthony.scarpino at oracle.com>
> *Gesendet: *Montag, 3. Dezember 2018 21:13
> *An: *Kasper Janssens <mailto:Kasper.Janssens at wdc.com>; 
> security-dev at openjdk.java.net <mailto:security-dev at openjdk.java.net>
> *Betreff: *Re: AES ctr benchmark performance
> 
> 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
> 
>  >
> 


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20181203/8e999560/attachment.htm>