Date: Sun, 11 Feb 2001 09:49:46 -0800 From: Kris Kennaway <kris@obsecurity.org> To: current@FreeBSD.org Subject: OpenSSL ASM patch Message-ID: <20010211094946.A51308@mollari.cthul.hu>
next in thread | raw e-mail | index | archive | help
--envbJBWh7q8WU6mo Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Okay, I've finally come up with a patch that enables the OpenSSL asm code in a way which is generically controllable and extends to other code which may want to enable CPU-specific optimizations (e.g. libgmp). The patch is at http://www.freebsd.org/~kris/openssl-asm.patch It's based on a patch originally by Mike Silbersack <mike@silby.com>, but the MACHINE_CPU stuff is mine and he shouldn't be blamed for it. Speedups are on the order of 3x-5x depending on the algorithm, for those which have asm cores available. Even the 386 should benefit from significant speed improvements, although I haven't tested this patch on a 386 or 486. It looks like the OpenSSL alpha asm code is broken (using the vendor build process doesn't build it either) - sorry, folks. The patch is fairly self-explanatory, and introduces a new variable called MACHINE_CPU which contains an unordered list of the CPU generations which we would like optimizations for, if present. Basically, this should be set to your CPU type plus all backwards-compatible revisions: e.g. MACHINE_CPU=i686 i585 i486 i386. I prefer doing it this way (MACHINE_CPU being a list) since it greatly simplifies the makefiles: For example, OpenSSL has Pentium ASM code for several algorithm cores in libcrypto. This code is what we want to compile on all "pentium class and above" CPUs (Pentium, PPro, Pentium II/III, AMD, ...), but there is also code for 686-class CPUs, and someday there may be AMD-optimized asm code, etc. If MACHINE_CPU is only a single word containing the exact CPU generation we intend to run on (e.g. "k6") then the makefile tests for whether to use the pentium code need to actually check for the name of all pentium-compatible CPUs and above, and if we miss one or the user uses a name we don't support then they won't get any optimization. Doing it as a list (i.e. MACHINE_CPU is a list of preferences or features we'd like) means that we can easily pick the best code to use based on what is available, and makes it more robust against mistakes. I'm not sure whether the way I've introduced MACHINE_CPU into sys.mk is the best way to do it, and whether make(1) also needs to be taught about it. I'd like to get this committed ASAP, please review. Kris --envbJBWh7q8WU6mo Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (FreeBSD) Comment: For info see http://www.gnupg.org iD8DBQE6htC5Wry0BWjoQKURAsZ1AJ9Ul30JD2/EXMPkR1AIyyrd/n0toQCZAZYe x6uYxE64+bHXv97dmnJjEp0= =XQNo -----END PGP SIGNATURE----- --envbJBWh7q8WU6mo-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20010211094946.A51308>