Subject: Re: [boost] [random] parallel random number generators
From: John Salmon (john_at_[hidden])
Date: 2012-01-29 11:47:42
On Sat, Jan 28, 2012 at 1:43 PM, Mathias Gaunard <
> On 01/27/2012 09:29 PM, John Salmon wrote:
> "Should there even be a cpuid check" is an excellent question. If
>> the answer is no, it certainly makes some portability headaches go away.
I also don't really think the code should do any cpuid check at all, since
> emitting AESNI instructions requires -maes, and whenever you use -maes the
> compiler is free to emit AESNI instructions whenever it wants.
> I have personally come to the conclusion that there should not be any,
> since that's the only model that is safe with all compilers.
> Also, this way, users don't pay for what they don't use. They're free to
> build the cpuid logic on top of it themselves through compiling the code
> several times with different settings.
The -maes option is gcc-specific. The Intel compiler, for example, does
not have an analogous command line option. Unlike with gcc, you can
#include <wmmintrin.h> and you can use the _mm_aesenc_si128() without any
command line option.
I think that it's important for the library to allow the programmer the
opportunity to decide about AESNI at compile-time, and also to allow the
programmer to defer the decision till runtime. If the decision is deferred
till runtime, I don't see how to choose a default without a cpuid check.
By the way, the code in aes_hasaesni.hpp that trashes %ebx, and is
therefore problematic with -m32 -fPIC is conditionalized on #ifdef
BOOST_HAS_AESNI. While I agree that the #ifdef logic to set
BOOST_HAS_AESNI needs work, I think it's safe to say that BOOST_HAS_AESNI
should never be set when -m32 is in effect.
> Unsubscribe & other changes:
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk