From owner-freebsd-current Thu Apr 27 16:37:22 2000 Delivered-To: freebsd-current@freebsd.org Received: from alcanet.com.au (mail.alcanet.com.au [203.62.196.10]) by hub.freebsd.org (Postfix) with ESMTP id 0B38C37B957; Thu, 27 Apr 2000 16:37:15 -0700 (PDT) (envelope-from jeremyp@pc0640.alcatel.com.au) Received: by border.alcanet.com.au id <115313>; Fri, 28 Apr 2000 09:37:44 +1000 From: Peter Jeremy Subject: Re: OpenSSL asm optimizations In-reply-to: ; from winter@jurai.net on Sat, Apr 22, 2000 at 02:35:51PM +1000 To: "Matthew N. Dodd" Cc: Kris Kennaway , current@FreeBSD.ORG Message-Id: <00Apr28.093744est.115313@border.alcanet.com.au> MIME-version: 1.0 X-Mailer: Mutt 1.0i Content-type: text/plain; charset=us-ascii References: Date: Fri, 28 Apr 2000 09:37:44 +1000 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG 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 majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message