Performance

Archived Posts from this Category

Wed 14 Mar 2012

OpenJDK, IcedTea & NSS: Results Without Hardware AES

Posted by gnu_andrew under IcedTea , OpenJDK , Performance
No Comments 

The following results are for IcedTea 6 & 7 using the NSS provider but without the hardware AES support enabled. It turns out that testing this scenario doesn’t require changing the NSS code; you merely need to set the environment variable NSS_DISABLE_HW_AES=1.

IcedTea6 with the NSS Provider but no hardware AES

Keysize 4k block, enc 4k block, dec 32k block, enc 32k block, dec 256k block, enc 256k block, dec 1024k block, enc 1024k block, dec
128 bit 7.04 ns/byte, 135MB/s 7.14 ns/byte, 134MB/s 5.93 ns/byte, 161MB/s 6.26 ns/byte, 152MB/s 6.28 ns/byte, 152MB/s 6.39 ns/byte, 149MB/s 6.31 ns/byte, 151MB/s 6.57 ns/byte, 145MB/s
192 bit 7.46 ns/byte, 128MB/s 7.72 ns/byte, 124MB/s 7.18 ns/byte, 133MB/s 7.54 ns/byte, 126MB/s 7.16 ns/byte, 133MB/s 7.27 ns/byte, 131MB/s 7.19 ns/byte, 133MB/s 7.48 ns/byte, 128MB/s
256 bit 8.34 ns/byte, 114MB/s 8.61 ns/byte, 110MB/s 8.25 ns/byte, 116MB/s 8.62 ns/byte, 111MB/s 8.04 ns/byte, 119MB/s 8.16 ns/byte, 116MB/s 8.10 ns/byte, 118MB/s 8.37 ns/byte, 114MB/s

IcedTea7 with the NSS Provider but no hardware AES

Keysize 4k block, enc 4k block, dec 32k block, enc 32k block, dec 256k block, enc 256k block, dec 1024k block, enc 1024k block, dec
128 bit 6.90 ns/byte, 138MB/s 6.81 ns/byte, 140MB/s 5.75 ns/byte, 166MB/s 5.97 ns/byte, 160MB/s 5.65 ns/byte, 169MB/s 5.91 ns/byte, 162MB/s 5.63 ns/byte, 169MB/s 5.89 ns/byte, 162MB/s
192 bit 7.17 ns/byte, 133MB/s 7.34 ns/byte, 130MB/s 6.64 ns/byte, 143MB/s 6.85 ns/byte, 139MB/s 6.54 ns/byte, 145MB/s 6.79 ns/byte, 140MB/s 6.52 ns/byte, 147MB/s 6.78 ns/byte, 140MB/s
256 bit 8.12 ns/byte, 117MB/s 8.23 ns/byte, 116MB/s 7.56 ns/byte, 126MB/s 7.80 ns/byte, 122MB/s 7.43 ns/byte, 129MB/s 7.69 ns/byte, 124MB/s 7.41 ns/byte, 129MB/s 7.67 ns/byte, 125MB/s

There is still a noticeable improvement using the NSS provider, but not as significant as when AES is handled in hardware. This does, however, mean that enabling NSS as the primary provider should show a benefit on all installs, not just ones with hardware AES.

I also found today that Oracle have enabled this provider with a priority of 2 on Solaris builds from jdk7u4 on; see bug 7088989 and this commit. Priority 1 is given to a proprietary provider, com.oracle.security.ucrypto.UcryptoProvider, the source of which is not included in OpenJDK.

 

Tue 13 Mar 2012

OpenJDK, IcedTea & NSS: IcedTea7 Results

Posted by gnu_andrew under IcedTea , OpenJDK , Performance
No Comments 

These were run about the same time as the last set, but didn’t have time to write them up last week.

IcedTea7 With the Default SunJCE Provider

Keysize 4k block, enc 4k block, dec 32k block, enc 32k block, dec 256k block, enc 256k block, dec 1024k block, enc 1024k block, dec
128 bit 9.47 ns/byte, 100MB/s 10.55 ns/byte, 90MB/s 8.97 ns/byte, 106MB/s 9.62 ns/byte, 99MB/s 8.99 ns/byte, 106MB/s 9.57 ns/byte, 100MB/s 8.96 ns/byte, 106MB/s 9.67 ns/byte, 99MB/s
192 bit 10.42 ns/byte, 91MB/s 11.45 ns/byte, 83MB/s 10.21 ns/byte, 93MB/s 10.98 ns/byte, 86MB/s 10.19 ns/byte, 93MB/s 11.02 ns/byte, 86MB/s 10.19 ns/byte, 93MB/s 11.08 ns/byte, 86MB/s
256 bit 11.54 ns/byte, 82MB/s 12.74 ns/byte, 74MB/s 11.53 ns/byte, 82MB/s 12.23 ns/byte, 78MB/s 11.39 ns/byte, 84MB/s 12.19 ns/byte, 78MB/s 11.50 ns/byte, 82MB/s 12.24 ns/byte, 78MB/s

IcedTea7 With the NSS Provider

Keysize 4k block, enc 4k block, dec 32k block, enc 32k block, dec 256k block, enc 256k block, dec 1024k block, enc 1024k block, dec
128 bit 2.59 ns/byte, 369MB/s 1.02 ns/byte, 950MB/s 1.63 ns/byte, 588MB/s 0.36 ns/byte, 2857MB/s 1.51 ns/byte, 645MB/s 0.30 ns/byte, 3333MB/s 1.50 ns/byte, 645MB/s 0.29 ns/byte, 3333MB/s
192 bit 2.42 ns/byte, 399MB/s 0.79 ns/byte, 1248MB/s 1.87 ns/byte, 512MB/s 0.39 ns/byte, 2500MB/s 1.79 ns/byte, 540MB/s 0.35 ns/byte, 2857MB/s 1.78 ns/byte, 540MB/s 0.34 ns/byte, 2857MB/s
256 bit 2.89 ns/byte, 332MB/s 0.90 ns/byte, 1109MB/s 2.25 ns/byte, 425MB/s 0.46 ns/byte, 2222MB/s 2.09 ns/byte, 465MB/s 0.40 ns/byte, 2500MB/s 2.07 ns/byte, 465MB/s 0.39 ns/byte, 2500MB/s

So 7 with NSS seems to be faster than 6 with NSS, especially with the larger block sizes. Not too surprising, given it has a newer version of HotSpot.

 

Fri 9 Mar 2012

OpenJDK, IcedTea & NSS

Posted by gnu_andrew under IcedTea , OpenJDK , Performance
[6] Comments 

OpenJDK has long had provision for cryptography support via NSS using the provider sun.security.pkcs11.SunPKCS11, but I get the impression it isn’t widely used or even known about. It requires some configuration to setup, as the OpenJDK build doesn’t look for NSS and the provider thus has to be manually configured with the location of the library. In September 2009, I added support to IcedTea to automate a lot of this, so you can now pass –enable-nss to the build and it will detect NSS and set it up in ${java.home}/jre/lib/security/java.security. I know Matthias Klose (doko) has used this, as he did further work on it within IcedTea, and I believe it may be enabled in Debian and/or Ubuntu builds. It’s also available (via USE=”nss”) in Gentoo, and it all three distros, it can be used to make elliptic curve cryptography available; this was the original motivation for adding support as noted in PR356.

Over the last week or so, we at Red Hat have been looking at whether using this NSS provider as the primary provider (i.e. listing it as number one in the java.security file) provides a performance advantage, specifically as concerns AES and the fact that newer chips have AES instructions which are supported by assembly code in NSS. We wrote a little test case which runs a number of encryption and decryption cycles (we ran with 20,000) and measures the average number of nanoseconds take to encrypt or decrypt each byte, and the amount of MB/s overall. We ran this on both IcedTea6 & IcedTea7 builds with and without the NSS provider enabled at the top priority. The results are below. The ns/byte figures are rounded to two decimal places. Tests were run on a 2.7GHz Intel Xeon E5-2680 machine with hardware AES instructions and 4 processors with 8 cores each, giving 32 cores, each with 20MB L3 cache.

IcedTea6 without the NSS provider

Keysize 4k block, enc 4k block, dec 32k block, enc 32k block, dec 256k block, enc 256k block, dec 1024k block, enc 1024k block, dec
128 bit 9.54 ns/byte, 99MB/s 10.57 ns/byte, 90MB/s 9.10 ns/byte, 105MB/s 9.80 ns/byte, 97MB/s 8.77 ns/byte, 108MB/s 9.35 ns/byte, 102MB/s 8.70 ns/byte, 109MB/s 9.43 ns/byte, 101MB/s
192 bit 10.42 ns/byte, 91MB/s 11.29 ns/byte, 84MB/s 10.66 ns/byte, 89MB/s 11.48 ns/byte, 83MB/s 9.95 ns/byte, 96MB/s 10.67 ns/byte, 89MB/s 10.23 ns/byte, 93MB/s 10.75 ns/byte, 88MB/s
256 bit 11.80 ns/byte, 80MB/s 12.79 ns/byte, 74MB/s 12.03 ns/byte, 79MB/s 12.98 ns/byte, 73MB/s 11.17 ns/byte, 85MB/s 11.96 ns/byte, 80MB/s 11.08 ns/byte, 86MB/s 12.00 ns/byte, 79MB/s

IcedTea6 with the NSS Provider

Keysize 4k block, enc 4k block, dec 32k block, enc 32k block, dec 256k block, enc 256k block, dec 1024k block, enc 1024k block, dec
128 bit 2.77 ns/byte, 344MB/s 1.16 ns/byte, 832MB/s 1.70 ns/byte, 571MB/s 0.44 ns/byte, 2222MB/s 1.99 ns/byte, 487MB/s 0.77 ns/byte, 1250MB/s 2.17 ns/byte, 444MB/s 1.01 ns/byte, 952MB/s
192 bit 2.66 ns/byte, 363MB/s 0.92 ns/byte, 1050MB/s 2.07 ns/byte, 476MB/s 0.51 ns/byte, 2000MB/s 2.28 ns/byte, 425MB/s 0.83 ns/byte, 1176MB/s 2.45 ns/byte, 392MB/s 1.05 ns/byte, 909MB/s
256 bit 2.97 ns/byte, 322MB/s 0.99 ns/byte, 998MB/s 2.30 ns/byte, 416MB/s 0.57 ns/byte, 1818MB/s 2.57 ns/byte, 377MB/s 0.88 ns/byte, 1111MB/s 2.75 ns/byte, 350MB/s 1.11 ns/byte, 869MB/s

There’s clearly a significant improvement when using the NSS provider on a machine with AES instructions. We still need to run more tests to see what the improvement (if any) is when using NSS without AES instructions. As an aside, an early version of the test didn’t show as significant an increase, instead more like a 1.6x speedup. We believe this was down to several issues:

  1. The entire process was being measured, including setup of the cipher, not just the encryption.
  2. The use of System.currentTimeMillis() rather than nanoseconds
  3. The use of doFinal where it returns a new array, rather than reusing the old one, thus creating significant garbage.

Update

Further results are collected in subsequent blogs: