Use cuRand instead of CPU random numbers

[roiser]

First implementation by Peter. Final done by AV

in eemumu_AV/master

Includes also the rambo part. Peter used curand device / API. AV used host / API (simpler code). AV used the fastest (not the “best”) generator.

[valassi]

Integrated here: roiser@9c10b20

Note that I am using the host API, unlike Peter that was using the device API. This is usefule because we can use the curand library also in c++ on a CPU with no GPU attached.

On a GPU with host API, the generation can be done both on the CPU host or on the GPU device. The default is now that it runs o device: this is simply a header #ifdef switch, roiser@847d158

About the choice of generator, see https://github.com/roiser/madgraph4gpu/blob/56a5b3af5a4df29a6e7020d2f3a4bc182fb5bb29/examples/gpu/eemumu_AV/src/rambo2toNm0.cc#L271

    // [NB Timings are for host generation of 32*256*1 events: rn(0) is 0.0012s]
    const curandRngType_t type = CURAND_RNG_PSEUDO_MTGP32;          // 0.0021s (FOR FAST TESTS)
    //const curandRngType_t type = CURAND_RNG_PSEUDO_XORWOW;        // 1.13s
    //const curandRngType_t type = CURAND_RNG_PSEUDO_MRG32K3A;      // 10.5s (better but slower)
    //const curandRngType_t type = CURAND_RNG_PSEUDO_MT19937;       // 43s
    //const curandRngType_t type = CURAND_RNG_PSEUDO_PHILOX4_32_10; // segfaults

The timings are the results of some tests I did while developing, The generator recommended by Lorenzo is MRG32K3A, but it is much slower. I then used MTPG32. On the other hand, we should check that this does not cause issues (eg is issue #20 related to the choice of random generator??)

[valassi]

This is clearly done. Curand is our default, and c++ common random is our backup.

I am closing this