Re: OpenSSL asm optimizations
On Fri, 21 Apr 2000, Kris Kennaway wrote: OpenSSL includes asm code for several platforms to speed up various operations. Currently we don't build any of this - the attached patch turns on asm code for Pentiums and above (it relies on an uncommitted patch to sys.mk which defined MACHINE_CPU ?= i386). Set MACHINE_CPU to "i586" or "i686" (both are actually identical at present) and rebuild. On Sat, Apr 22, 2000 at 02:35:51PM +1000, Matthew N. Dodd wrote: Can these be turned on at runtime? Not the way the libraries are currently structured. There are a number of libraries where we would get significant speedups by supporting target-dependent code. I can think of three possible ways of supporting this: 1) Use machine-depend shared libraries to replace functions in the standard shared libraries. This approach is used on Solaris - the rtld automatically loads a machine-specific library (if it exists) before libc.so. The disadvantages are: - no support for static executables or in-line functions - slower startup due to the extra libraries (particularly if Kris's idea of an ordered list of machine architectures) - increased VM usage due to multiple function versions in the process address space - I'm not sure how difficult it would be to integrate into FreeBSD's lazy binding scheme 2) Use indirect function calls, with run-time initialisation to setup the pointers. This approach is used in the kernel for bzero/bcopy. The disadvantages are: - no support for in-line functions - need to invoke a library initialisation routine (not too difficult with ELF) - increased function call overheads (indirect rather than direct calls). - increased VM usage due to multiple function versions in the process address space 3) Have separate library versions for each target. - Significant increase in disk space occupied by libraries All the approaches increase the build time since multiple copies of functions need to be built. Peter To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: OpenSSL asm optimizations
On Fri, Apr 21, 2000 at 07:28:28PM -0700, Kris Kennaway wrote: patch to sys.mk which defined MACHINE_CPU ?= i386). Set MACHINE_CPU to "i586" or "i686" (both are actually identical at present) and rebuild. Please also support "k5" and "k6". -- -- David([EMAIL PROTECTED]) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: OpenSSL asm optimizations
On Mon, 24 Apr 2000, David O'Brien wrote: On Fri, Apr 21, 2000 at 07:28:28PM -0700, Kris Kennaway wrote: patch to sys.mk which defined MACHINE_CPU ?= i386). Set MACHINE_CPU to "i586" or "i686" (both are actually identical at present) and rebuild. Please also support "k5" and "k6". Actually it raises the question I was going to frame of how to specify the set of CPU revisions which are compatible. For example, k5 and k6 want i586 optimizations as a fallback (if no k5/6 native optimizations available), k6 wants k5, i586 wants i486 etc. The easiest way I can think of is to specify MACHINE_CPU as a list: e.g. for a k6 it might be "k6 k5 i586 i486 i386" specifying that any of those optimizations should be used. It would be best to make it an ordered list, i.e. in order of preference, but I'll have to think about the implementation implications. Kris In God we Trust -- all others must submit an X.509 certificate. -- Charles Forsythe [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: OpenSSL asm optimizations
Can these be turned on at runtime? My concern is that build systems that compile for other machines not generate code dependent on the machine thats building the code. On Fri, 21 Apr 2000, Kris Kennaway wrote: OpenSSL includes asm code for several platforms to speed up various operations. Currently we don't build any of this - the attached patch turns on asm code for Pentiums and above (it relies on an uncommitted patch to sys.mk which defined MACHINE_CPU ?= i386). Set MACHINE_CPU to "i586" or "i686" (both are actually identical at present) and rebuild. Typical speed improvements are between 2x and 5x for BigNum, Blowfish, CAST, DES, MD5, RC4, RC5, RIPEMD-160, and SHA-1 operations, as measured by 'openssl speed' on my Pentium Pro 233 (speeds are in K/sec for packets of the given size): === BLOWFISH === type 8 bytes 64 bytes256 bytes 1024 bytes 8192 bytes blowfish cbc 3325.35k 4417.62k 4553.81k 4572.46k 4595.71k type 8 bytes 64 bytes256 bytes 1024 bytes 8192 bytes blowfish cbc 7073.58k 8099.29k 8286.63k 8328.53k 8315.07k === CAST === type 8 bytes 64 bytes256 bytes 1024 bytes 8192 bytes cast cbc 3249.59k 4231.19k 4394.88k 4401.69k 4437.97k type 8 bytes 64 bytes256 bytes 1024 bytes 8192 bytes cast cbc 6956.17k 7999.28k 8208.47k 8199.05k 8192.00k === DES === type 8 bytes 64 bytes256 bytes 1024 bytes 8192 bytes des cbc 2291.38k 2404.86k 2426.97k 2436.64k 2443.95k des ede3 492.61k 516.87k 519.83k 521.18k 520.20k type 8 bytes 64 bytes256 bytes 1024 bytes 8192 bytes des cbc 4830.90k 5301.97k 5412.18k 5419.02k 5355.72k des ede3 1831.93k 1919.80k 1929.86k 1932.36k 1913.72k === MD5 === type 8 bytes 64 bytes256 bytes 1024 bytes 8192 bytes md5 1636.10k 7736.92k13991.76k17495.04k18879.83k type 8 bytes 64 bytes256 bytes 1024 bytes 8192 bytes md5 2609.84k13585.19k26511.38k34934.97k38629.09k === RC4 === type 8 bytes 64 bytes256 bytes 1024 bytes 8192 bytes rc4 12947.45k16970.70k18044.59k18370.22k18275.58k type 8 bytes 64 bytes256 bytes 1024 bytes 8192 bytes rc4 18209.51k25287.65k26100.65k26139.99k26512.82k === RC5 === type 8 bytes 64 bytes256 bytes 1024 bytes 8192 bytes rc5-32/12 cbc 5115.15k 8124.08k 8766.29k 8814.59k 8928.03k type 8 bytes 64 bytes256 bytes 1024 bytes 8192 bytes rc5-32/12 cbc12462.59k15226.54k15804.76k16218.86k16447.82k === RIPEMD-160 === type 8 bytes 64 bytes256 bytes 1024 bytes 8192 bytes rmd160 849.94k 3680.04k 6326.22k 7626.07k 8123.73k type 8 bytes 64 bytes256 bytes 1024 bytes 8192 bytes rmd1601279.72k 5915.67k10461.46k12978.21k13944.41k === SHA1 === type 8 bytes 64 bytes256 bytes 1024 bytes 8192 bytes sha1 1081.31k 2844.71k 5784.80k 7765.50k 8650.75k type 8 bytes 64 bytes256 bytes 1024 bytes 8192 bytes sha1 1617.59k 7664.76k13538.05k17012.18k18419.89k Kris In God we Trust -- all others must submit an X.509 certificate. -- Charles Forsythe [EMAIL PROTECTED] -- | Matthew N. Dodd | '78 Datsun 280Z | '75 Volvo 164E | FreeBSD/NetBSD | | [EMAIL PROTECTED] | 2 x '84 Volvo 245DL| ix86,sparc,pmax | | http://www.jurai.net/~winter | This Space For Rent | ISO8802.5 4ever | To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: OpenSSL asm optimizations
On Sat, 22 Apr 2000, Matthew N. Dodd wrote: Can these be turned on at runtime? My concern is that build systems that compile for other machines not generate code dependent on the machine thats building the code. I probably meant TARGET_CPU, but that's easily taken care of. Kris In God we Trust -- all others must submit an X.509 certificate. -- Charles Forsythe [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
