Hi,
I need a little advice. I am writing an md code for a specific problem but am having some problems when I go to larger system sizes. My code seems to work perfectly for smaller system sizes (up to about 32000) but when I am trying to go to bigger system sizes I get massive slowdown. I have tracked it down to the thing that causes it but it is very strange.
In the force routine, I calculate the acceleration on a particle at the end of it. I have have variables declared within the kernel so each thread will have a copy of this variable and I collect the forces on a particle in these. The acceleration is stored in a variable declared with cudamalloc and used in other routines. If I write to the acceleration with a variable declared within the kernel I struggle to transfer a different variable to the host. If I write to the acceleration with something from constant memory I get no slowdown. Everything is the same, the only difference is the variable copied from.
So to be clearer here is some psuedo-code in 1d. I have
global void forcesolvent( double *solventa_x, double *solventr_x){
double F_x, modrij13, modrij7, drijx
|
some stuff to calculate
|
solventa_x = F_x*solventinvmass
}
solventinvmass is in constant memory. This causes a massive delay when copying a completely different variable (the kinetic energy).
As I only get this problem with larger systems, I was wondering if this might be a memory problem so I was wondering if there was a way of checking for memory problems, as in trying to claim too much memory. I don’t think this is a problem as I am running on a GTX470 and this has one gig of memory. Even if I assume I claim 25 times the number of particles in double precision (I am mostly in double precision) I claim around 13.1MBytes. Having an order of magnitude to spare should be safe for the amount of memory I claim.
Also how do I know I am not claiming too many registers for a kernel? I print out the number of registers per kernel at compile time but don’t really understand how to tell whether I am causing problems.
Thanks for any advice you can offer…
Dean Wood