Hello, I have a question about curandGenerateUniform().
I have the following code for comparisson between times of generation of random numbers in java and jcuda (or it’s that I believe to do).
With N = 16,000,000 of floats I get the same times.
What happen? Shouldn’t be faster with jcuda?
import java.util.Random;
import static jcuda.jcurand.JCurand.*;
import static jcuda.jcurand.curandRngType.CURAND_RNG_PSEUDO_DEFAULT;
import static jcuda.runtime.JCuda.*;
import jcuda.*;
import jcuda.jcurand.*;
public class Main {
public static void main(String[] args) {
int n = 16000000;
System.out.println("generar: " + n);
float array[] = new float[n];
////JAVA////
int i = 0;
Random numAleatorio = new Random();
long timeStart = System.currentTimeMillis();
for(i = 0; i < n; i++){
array** = numAleatorio.nextFloat();
}
long timeEnd = System.currentTimeMillis();
long time = (timeEnd - timeStart);
System.out.println("time JAVA: " + time);
///FIN JAVA////
///JCUDA///
curandGenerator g = new curandGenerator();
curandCreateGenerator(g, CURAND_RNG_PSEUDO_DEFAULT);
Pointer arrayCuda = new Pointer();
cudaMalloc(arrayCuda, n * Sizeof.FLOAT);
timeStart = System.currentTimeMillis();
curandGenerateUniform(g, arrayCuda, n);
timeEnd = System.currentTimeMillis();
System.out.println("time JCUDA: " + time);
curandDestroyGenerator(g);
cudaFree(arrayCuda);
}
}
Of course, Essence is right.
Apart from that, JCurand is not a replacement of java.util.Random. It might even be slower in this case (although I think it should be faster). The algorithm for computing the „random“ numbers (this DOES sound contradictory, right? ;)) is different in both cases. As far as I know, JCurand should be delivering „high quality“ random numbers, which may, for example, be used in kryptography or some stochastical experiments (but don’t pin me down to this … I just wrote the Java bindings )
If speed of random numbers is important to you, it is worth looking at some different Java implementations, eg from apache commons math library (which is growing in my estimation, there is a lot more in it now than there was a year ago). There is an overview of which methods are appropriate for different cases. It seems the JDK method is NOT suitable for cryptography.
But surely random number generation is so fast that it is unlikely to be a bottleneck?
Most likely, getting these numbers in host memory will take longer. But at least there is a potential speedup (and a substantial one when the numbers are required in device memory, of course)
)