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@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.scarp...@oracle.com> > *Gesendet: *Montag, 3. Dezember 2018 21:13 > *An: *Kasper Janssens <mailto:kasper.janss...@wdc.com>; > security-dev@openjdk.java.net <mailto:security-dev@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 > > > >
