On Fri, Nov 19, 2021 at 9:52 AM Derek Chen-Becker <de...@chen-becker.org> wrote: > > https://bugs.openjdk.java.net/browse/JDK-7184394 added AES intrinsics in > Java 8, in 2012. While it's always possible to have a regression, and it's > important to understand the performance impact, stories of 2-10x sound > apocryphal. If they're all using the same intrinsics, the performance > should be roughly the same. I think that the real challenge will be key > management, not performance. > > Derek
> On Fri, Nov 19, 2021 at 7:41 AM Bowen Song <bo...@bso.ng.invalid> wrote: > > > On the performance note, I copy & pasted a small piece of Java code to > > do AES256-CBC on the stdin and write the result to stdout. I then ran > > the following two commands on the same machine (with AES-NI) for > > comparison: > > > > $ dd if=/dev/zero bs=4096 count=$((4*1024*1024)) status=none | time > > /usr/lib/jvm/java-11-openjdk/bin/java -jar aes-bench.jar >/dev/null > > 36.24s user 5.96s system 100% cpu 41.912 total > > $ dd if=/dev/zero bs=4096 count=$((4*1024*1024)) status=none | time > > openssl enc -aes-256-cbc -e -K > > "0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef" > > -iv "0123456789abcdef0123456789abcdef" >/dev/null > > 31.09s user 3.92s system 99% cpu 35.043 total > > > > This is not an accurate test of the AES performance, as the Java test > > includes the JVM start up time and the key and IV generation in the Java > > code. But this gives us a pretty good idea that the total performance > > regression is definitely far from the 2x to 10x slower claimed in some > > previous emails. > > > > I am aware that Java added AES intrinsics support in Java 8, but it is still painfully slow doing authenticated AES-GCM and many other forms of crypto [1]. Native AES-GCM on my laptop running at 4GHz [2] achieves 3.7 GiB/s while Java 8 can manage a mere 289 MiB/s (13x slower) and Java 11 manages 768 MiB/s (5x slower) [3]. AWS literally funded an entire project [4] to speed up slow Java crypto which has sped up basic crypto from 2-10x [5, 6] on real world workloads at scale. I don't think my claims are apocryphal when I and others have spent so much time on this project and other JVM projects debugging why they are so slow, including most recently determining the root cause to the initial serious performance regressions in 4.0's networking code was due to native Java 8's TLS stack and specifically AES-GCM implementation being painfully slow (the fix we settled on was to use tcnative with native AES-GCM) [6] as well as speeding up quorum reads by 2x through using faster MD5 crypto [8, 9, 10]. -Joey [1] https://gist.github.com/jolynch/a6db4409ddae8d5163894bef77204934#file-summary-txt [2] https://gist.github.com/jolynch/a6db4409ddae8d5163894bef77204934#file-benchmarkon-sh [3] https://gist.github.com/jolynch/a6db4409ddae8d5163894bef77204934#file-authenticated_encryption_perf-txt [4] https://github.com/corretto/amazon-corretto-crypto-provider [5] https://github.com/corretto/amazon-corretto-crypto-provider/pull/54 [6] https://github.com/corretto/amazon-corretto-crypto-provider/issues/52 [7] https://issues.apache.org/jira/browse/CASSANDRA-15175 [8] https://issues.apache.org/jira/browse/CASSANDRA-14611 [9] https://issues.apache.org/jira/browse/CASSANDRA-15294 [10] https://github.com/corretto/amazon-corretto-crypto-provider/issues/52#issuecomment-531921577 --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org For additional commands, e-mail: dev-h...@cassandra.apache.org
