Re: [boost] [random] parallel random number generators

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 <
mathias.gaunard_at_[hidden]> wrote:

> 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:
> http://lists.boost.org/mailman/listinfo.cgi/boost
>