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

Subject: Re: [boost] [random] parallel random number generators
From: John Salmon (john_at_[hidden])
Date: 2012-01-27 15:29:34

On Thu, Jan 26, 2012 at 2:06 PM, Mathias Gaunard <
mathias.gaunard_at_[hidden]> wrote:

> On 01/25/2012 08:55 PM, John Salmon wrote:
>
>  A couple of weeks ago, I asked if there was interest in a parallel RNG in
>> boost.
>> Here's a pointer to my original post:.
>>
>> http://lists.boost.org/**Archives/boost/2012/01/189293.**php
>

>>
>> Our paper on parallel random number generators is here:
>> http://dl.acm.org/citation.**cfm?doid=2063405
>
>> also available at
>>
http://www.thesalmons.org/**john/random123/papers/**random123sc11.pdf
>
>>
>> Source (non-boost) is available here:
>>
http://deshawresearch.com/**resources_random123.html
>
>>
>> And software that might be a starting point for a boost contribution is
>> here:
>>
http://thesalmons.org/john/**random123/prf_boost/prf_boost.**zip
>
>>
>> Feedback is appreciated.
>>
>
> The above code seems quite more readable than the one from the
> deshawresearch website, but also a bit shorter.
> Does it do everything the deshawresearch does?
>

The functionality is the same.  The original Random123 library
(deshawresearch website) is C-compatible and also works with CUDA and
OpenCL development environments. Dropping C, CUDA and OpenCL support and
making effective use of templates and classes greatly clarifies/simplifies
the code..

>
> I see you're using inline asm for mulq on GCC, but you don't use __umulh
> for MSVC.
> I can't see any hit for _mm_clmulepi64_si128 (which I assume would be
> useful).
>

> Your cpuid code won't work with gcc -m32 -fPIC, and also doesn't appear to
> take care of register trashing properly.
> 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.
>

> From what I see, you only use SSE instructions if AESNI is available. Is
> that really desirable?
>
> There is a library proposed for Boost that abstracts SIMD instructions and
> scalar built-ins (Boost.SIMD), it might be interesting to use it / extend
> it to take care of all the platform-specific bits.
>

These are clearly areas that need work.  In terms of portability, the
current version is at the proof-of-concept stage, not the release-ready
stage.  "Should there even be a cpuid check" is an excellent question.  If
the answer is no, it certainly makes some portability headaches go away.
How best to accomodate compiler-specific and hardware-specific intrinsics
and asm is another open question.  I'm open to considering more, or less,
use of SSE, and I'd be very happy to let another library do the heavy
lifting in terms of portability.

John Salmon

> In any case I think this would be a very interesting contribution to Boost
> and the open-source community in general.
>
>

>
> ______________________________**_________________
> Unsubscribe & other changes: http://lists.boost.org/**
> mailman/listinfo.cgi/boost<http://lists.boost.org/mailman/listinfo.cgi/boost>
>