> On Mar 7, 2016, at 5:01 AM, Ben Laurie <b...@links.org> wrote: > > On 7 March 2016 at 09:59, Andy Polyakov <ap...@openssl.org> wrote: >>>>>> Hmm. So why do I see this on my macbook? >>>>>> >>>>>> $ arch >>>>>> i386 >>>>> >>>>> Try "uname -m" >>>> >>>> This is not reliable. Because it must have changed recently, it used to >>>> be i386 even on 64-bit systems. sysctl -n hw.optional.x86_64 is the way >>>> to go, it's right there in ./config... >>> >>> Sure, and that is used to decide whether to offer the 64 bit version. >>> But its not helping me on what should be default. >> >> I thought suggestion was to default to 64 bit whenever it is an option. >> And uname -m *was* returning i386 even on system capable of executing >> 64-bit code. So that sysctl is something that works in *either* situation. > > The question is: which is better? I've been told there's no advantage > to 64 bit on MacOS unless you need the extra address space - if that's > so, then we should default to 32 bit, I think.
As with all x86-64 systems, compiling for 64-bit will enable the compiler to use many more registers, generally resulting in faster code. The same is _not_ true of 64-bit PPC, where the advice you list above is (almost) accurate. Don’t compile for 64-bit PPC unless you need the extra address space, or you need instructions that are only available for the 64-bit processor. I suspect the advice you heard was geared toward Mac OS on PPC, not x86. I haven’t checked out everything in OpenSSL, but I can say that several programs I’ve written which use OpenSSL for SHA-2, SHA-1, MD5, AES, and 3DES run the crypto routines _much_ faster when compiled as 64-bit than as 32-bit (that was not isolating OpenSSL’s libcrypto, but isolating the code that invoked those routines). The overall application performance was also greatly improved. Memory usage was slightly higher, since pointers are larger, of course. And that held true for Mac OS X (10.6 and later), Windows (2003 Server - 2012 Server and 7 and later), Linux (don’t remember which kernels), and FreeBSD (8.0 and later). I expect it’ll continue to hold true, so I don’t expect to keep testing it. > -- > openssl-dev mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev > -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
