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.


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Reply via email to