On Thu, Jan 26, 2012 at 2:06 PM, Mathias Gaunard < mathias.gaunard@ens-lyon.org> 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:.
Our paper on parallel random number generators is here: http://dl.acm.org/citation.**cfm?doid=2063405<http://dl.acm.org/citation.cfm?doid=2063405> also available at http://www.thesalmons.org/**john/random123/papers/**random123sc11.pdf<http://www.thesalmons.org/john/random123/papers/random123sc11.pdf>
Source (non-boost) is available here: http://deshawresearch.com/**resources_random123.html<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<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>