This is on a Haswell Macbook Pro: $ sysctl -n machdep.cpu.brand_string Intel(R) Core(TM) i7-4850HQ CPU @ 2.30GHz
AFAIKT JDK-7184394 only dealt with using AES-NI (and some SIMD for AES/CBC) - am I missing something? cheers tim On 28/03/2014, at 9:37 pm, Ivan Krylov <i...@azulsystems.com> wrote: > 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 >> >> >
