On 01/27/2012 09:29 PM, John Salmon wrote:
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..
Would it possible to keep CUDA support still, since it supports C++? There is a BOOST_GPU_ENABLED macro in Boost that will expand to __host__ __device__ if using CUDA.
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.
To submit your library for review, you'll need more than proof-of-concept, if not necessarily release-ready code. You'll also need documentation, but that part should be pretty short.
"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 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.
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.
I am one of the authors of Boost.SIMD, which isn't a Boost library yet (there are problems with compile-time performance that I'd like to fix first, and it seriously lacks documentation). If you wish to depend on it (which might delay getting a review, but your code doesn't seem to be review-ready just yet in any case) I'd be happy to help.