Hello. I attach patch containing code that is supposed to initialise Sobol32 direction vectors. Initially I wanted to implement it myself based on article, but after looking at CUDA 4.0 (and new functions that would also need to be reimplemented) I decided just to call existing function in library. Few remarks about implementation: 1) I have added new option to configure.py and new configuration variable HAVE_LIBRARIES It might not be ideal for CURAND, but I am also thinking about additional libraries that are available in CUDA 4.0 in cudatoolssdk_4.0_linux_64.run. I believe that it might be possible to include CURAND in the PyCUDA core (and hence add dependency on libcurand), but I also believe that dependency on e.g. libcupti should be optional. In such case I would propose changing name from HAVE_LIBRARIES to HAVE_TOOLS and changing patch not to surround CURAND-related code with ifdefs. 2) I have added enum direction_vector_set; currently it has only one value, but it will have more in CUDA 4.0 - so please leave it as is. 3) Although there is ability to call function get_direction_vectors32 and to create object Sobol32* there is no code that joins those two. I am thinking whether this code should be in C or in Python - so for now please just apply patch to curand branch, and after I have good implementation I will send it to the list. 4) Sorry - no documentation for C code yet.

Dnia 2011-03-17 13:09 Andreas Kloeckner napisał(a): >Hi Tomasz, > >On Tue, 15 Mar 2011 23:25:32 +0100, "=?UTF-8?B?VG9tYXN6IFJ5YmFr?=" <bogomips(a)post.pl&gt; wrote: >> Hello. >> I attach patch containing code that is supposed to initialise Sobol32 >> direction vectors. >> Initially I wanted to implement it myself based on article, but after >> looking at CUDA 4.0 >> (and new functions that would also need to be reimplemented) I decided just >> to call existing >> function in library. >> >> Few remarks about implementation: >> 1) I have added new option to configure.py and new configuration

>> HAVE_LIBRARIES >> It might not be ideal for CURAND, but I am also thinking about

>> libraries that are >> available in CUDA 4.0 in cudatoolssdk_4.0_linux_64.run. >> I believe that it might be possible to include CURAND in the PyCUDA core >> (and hence >> add dependency on libcurand), but I also believe that dependency on e.g. >> libcupti should be optional. >> In such case I would propose changing name from HAVE_LIBRARIES to HAVE_TOOLS >> and changing >> patch not to surround CURAND-related code with ifdefs. >> >> 2) I have added enum direction_vector_set; currently it has only one value, >> but it will have more >> in CUDA 4.0 - so please leave it as is. >> >> 3) Although there is ability to call function get_direction_vectors32

to >> create object Sobol32* >> there is no code that joins those two. I am thinking whether this code >> should be in C or in Python >> - so for now please just apply patch to curand branch, and after I have >> good implementation >> I will send it to the list. >> >> 4) Sorry - no documentation for C code yet. > >Thanks for the patch! > >A few comments/requests: > >- Don't error out on 'import pycuda.curandom' if CURAND wasn't > found. The old MD5 RNG is still there and will work even if nothing > else does. I have also changed definition of classes depending on CURAND so now they are created only if proper CURAND version is present. > > Same goes for have_libraries()--I'd prefer get_curand_version() in > [None, (3,2), ... ] etc. Use (0, 0, 0) instead of None > >- Make the HAVE_* options more fine-grained, i.e. HAVE_CURAND. > >- Compile a separate shared library for every extension. _driver.so is > called that because it's supposed to contain the wrapper for the > driver interface, and nothing else. > > My suggestion would be _curand.so. (Just add another Extension object > in setup.py.) All done - attaching patch for analysis.