Tim, Do you have a Haswell powered machine at your disposal? JDK-7184394[1] should have addressed this issue
Thanks, Ivan [1] - https://bugs.openjdk.java.net/browse/JDK-7184394 On 28 Mar 2014, at 01:29, Tim Whittington <jdk-security-...@whittington.net.nz> wrote: > Hi all > > I’ve noticed that the performance of the AES/GCM implementation in the JDK 8 > SunJCE provider is very slow. > > On a simple micro-benchmark (standard caveats etc. etc.) encrypting 10 MB > blocks of random data (not decrypt) I get the following rough throughputs: > > AES/ECB +UseAESIntrinsics - 600 MB/s (btw this is awesome fast for Java, up > from about 300 MB/s in Java 7) > AES/ECB -UseAESIntrinsics - 120 MB/s (again a good bump from about 90 MB/s in > Java 7) > AES/GCM - 4 MB/s > > 4 MB/s is pretty catastrophic (especially compared to the stellar baseline > AES performance). > > A quick peek in a profiler reveals pretty much all the time is in > GHash.blockMult()/getBit()/shift(). > The performance of the AES/GCM mode is comparable to other pure Java > implementations without table based multiplier optimisations (which typically > provide speeds in the 40-60 MB/s on the same micro-benchmark). > > I wonder if the JDK implementation could adopt one of those approaches or > (better) implement an intrinsic to speed this up (perhaps using the CLMUL > interaction set when available). > > cheers > tim > > — > > java version "1.8.0" > Java(TM) SE Runtime Environment (build 1.8.0-b132) > Java HotSpot(TM) 64-Bit Server VM (build 25.0-b70, mixed mode) > > Darwin <redacted> 13.1.0 Darwin Kernel Version 13.1.0: Thu Jan 16 19:40:37 > PST 2014; root:xnu-2422.90.20~2/RELEASE_X86_64 x86_64 > >
