Re: [WBEL-devel] Re: openssl security update needed
Lamar Owen <[email protected]> Sat, 20 Mar 2004 10:39:53 -0500
| Newsgroups | gmane.linux.whitebox.devel |
|---|---|
| Organization | Pisgah Astronomical Research Institute |
| Message-ID | <[email protected]> |
On Friday 19 March 2004 06:20 pm, Jamey Fletcher wrote: > And there are issues John's discovered, and others have pointed out, why > packages should in general be built for i686, with only a very few > exceptions being built *specifically* for i586. In fact, I *think* you're > supposed to even built *those* in some weird mode that does a "i686 > *except* for those funky instructions that don't exist on a i586" - some > memory monitoring registers, I think. More specifically, most are built with '-march=i386 -mcpu=i686' which both optimizes for i686 instruction ordering but can still be run on earlier CPU's. The -march=i386 makes it an '.i386.rpm' but that's OK, since the instruction ordering is still optimized for i686. It is a tad confusing, but it works, and the performance benefits of '-march=i686 -mcpu=i686' are miniscule for OpenSSL. On non-i386 architectures it's a bigger issue to optimize -march, since with those typically you get enough newer instructions to make it useful to optimize for the particular CPU for OpenSSL. In particular, SPARC V7 (sun4c) is very slow in dealing with SSL stuff. SPARC V8 adds instructions that help, and V9/SPARC64 adds yet more. So while you can install the plain sparc (which is V7) RPM of OpenSSL on a V8 (sun4m) or V9/64 (UltraSPARC is 64 and V9, and I think maybe HyperSPARC is a sortof V9 but 32 bit, although the UltraSPARC RPMs are not 64bit, so their arch is 'sparcv9' instead of sparc64) your performance stinks if you do. OpenSSL is one of the very few cases that that is so, except for the kernel and glibc, of course. Although the RPMs for the Aurora SPARC Linux dist even on 32 bit SPARCs are compiled with UltraSPARC optimized ordering, that is '-march=sparc -mcpu=ultrasparc'. Oh, but even on the 64 bit UltraSPARC you use 32 bit userland, only the kernel is 64 bit, along with portions of glibc. Performance is better that way; typical 32 bit code on the Ultra executes more quickly and takes up less space and memory than 64 bit code in user mode, at least under Linux. Only when you need huge numbers or huge amounts of memory do you need 64 bit code (UltraSPARC servers can easily have 8 or more CPUs with 16 or even 64GB of RAM in the larger configurations). Lovely stuff, no? :-) -- Lamar Owen Director of Information Technology Pisgah Astronomical Research Institute 1 PARI Drive Rosman, NC 28772 (828)862-5554 www.pari.edu