Add feature to produce common random numbers.

[hageboeck]

• Add a header in tools/ for creating reproducible common random numbers using c++11.
• Modify eemumu_AV such that it can make use of those.

Note that to increase the compiler coverage and to decrease the probability of errors, this uses

#define FLAG true/false
...
if (FLAG)

This way, the compiler checks both code paths for correct syntax, but no assembly is generated for the inactive path.

[roiser]

alles gut

[valassi]

Hi @hageboeck and @roiser thanks for the commit!

One point, I would prefer to have all #defines to generate #ifdefs in the code, rather than if(true) or if(false), at this stage. I do not claim that what I have done so far is the best option, but I'd like to have a consistent way to set this: so far, this is choosing one and only one of the #defines for each option in the config file.

Is it ok for you if I modify that in this direction? (By the way I have made quite a few changes that I'm about to push, so I merged already a minor conflict).

Thanks
Andrea

[valassi]

One other point, I'd rather keep some naming consistent (sorry, my definition of consistent ;-).

For instance I'd stick with hstRnarray as the thing that is passed between random number generation and rambo. Now there is an additional hstRn, I thought that was used to populate hstRnarray but it is a bit the opposite. I would also change that.

[valassi]

Sorry, one more point. Especially as we know this is not meant to be a production system but a solution to validate random numbers on host and device, I would favor clarity and metric calculation over speed. I mean, I am not sure I would use a vector that gets precomputed in async mode and has the size of #iterations. This is actually a nice smart trick! But I prefer to get it much clearer in the code how much time is spent in each phase. Eventually I may need to eat this back... but for now I'd stay with simpler code and generate random numbers at the beginning of each iteration.

Or maybe not. I need to think about it...

One possible issue is that these arrays can easily get far too large if they cover all iterations. Starting a new sequence (and reseeding) in each iteration would consistently follow what is done in the curand solution.

[hageboeck]

Hi @hageboeck and @roiser thanks for the commit!

One point, I would prefer to have all #defines to generate #ifdefs in the code, rather than if(true) or if(false), at this stage. I do not claim that what I have done so far is the best option, but I'd like to have a consistent way to set this: so far, this is choosing one and only one of the #defines for each option in the config file.

Is it ok for you if I modify that in this direction? (By the way I have made quite a few changes that I'm about to push, so I merged already a minor conflict).

Thanks
Andrea

Sure, I actually tried that but gave up, because both CPU and GPU work with/without common numbers. That is, you need 4 instead of 2 cases to be defined or not, which means that 3/4 of the cases are not checked by the compiler, and that you have to cycle through all four until you know that the code compiles.
Can be done, though.

On a related note:
Would constexpr bool someFlag = true/false be on option?

• The code of both branches is checked by the compiler.
• Assembly is only generated for the active branch.

[hageboeck]

One other point, I'd rather keep some naming consistent (sorry, my definition of consistent ;-).

For instance I'd stick with hstRnarray as the thing that is passed between random number generation and rambo. Now there is an additional hstRn, I thought that was used to populate hstRnarray but it is a bit the opposite. I would also change that.

This can also be done, but it needs more ifdefs. I had also done that, but when I realised that more and more code hides behind ifdefs, I pulled it out.
... unless I misunderstand and you just want a variable to be renamed.

[hageboeck]

Sorry, one more point. Especially as we know this is not meant to be a production system but a solution to validate random numbers on host and device, I would favor clarity and metric calculation over speed. I mean, I am not sure I would use a vector that gets precomputed in async mode and has the size of #iterations. This is actually a nice smart trick! But I prefer to get it much clearer in the code how much time is spent in each phase. Eventually I may need to eat this back... but for now I'd stay with simpler code and generate random numbers at the beginning of each iteration.

Or maybe not. I need to think about it...

One possible issue is that these arrays can easily get far too large if they cover all iterations. Starting a new sequence (and reseeding) in each iteration would consistently follow what is done in the curand solution.

Yes, can also be done, but I was asked specifically if it's possible to do it in parallel. It's changing three lines of code or so, because CommonRandomNumbers.h exposes the function that creates a batch of random numbers.

[valassi]

Hi Stephan, thanks... and sorry for being a pain :-)
Before I comment on your replies, I noticed one more fundamental issue (while fixing ifdefs, which indeed gets complex!): when using curand on host, hstRnarray is a pinned memory array (using cudaMalloc), while using the common random generator essentially an std::vector is created and then its data() is used as C-array to be copied over to CUDA. In this case, the memory copy from host to device does an intermediate copy to pinned memory in any case, see https://developer.nvidia.com/blog/how-optimize-data-transfers-cuda-cc/. After looking this up, I find it easier to just use hstRnarray as pinned memory, and then memcpy the vector's data() to that pinned host array: this is what would in any case happen behind the scenes if we copied directly data() to the GPU, but at least it allows a simplifaction of the code about what hstRnarray is. This extra memcpy is very ugly, but I think is unavoidable. A nice improvement in your algo, if possible, would be to fill the preallocated rnArray rather than creating a new vector, maybe this is possible? For this validation code it is not essential, but I think it helps to think in terms of pinned memory even here.

That said, I saw your PR #47 which has many interesting and relevant points! But I'd like to complete this one first...

Thanks! Lets discuss maybe at coffee tomorrow morning
Andrea

[valassi]

About your replies now:

• I think the ifdefs are indeed a mess. Again, not sure this is the best, but I'd like to stay consisten with teh rest. A constexpr? I have not thought of that. Maybe I suggest to stay with the options we have now, and reassess after tomorrow's LHCb/ALICE talks, eventually we may need ifdefs also for AMD etc etc

• About the async and parallel, you ar eright, in the end I am keeping that in. Maybe the timers get some slightly changed meanings, but ok. I am trying to make sure the timers are relatively consistent with the rest anyway (this is one thing I was working on this morning in PR Fix throughput metrics and improve float printouts. Merge (fixing conflicts) with @shageboe's common random nubers on host. #46

A demain
Andrea

[valassi]

Ok I have merged the changes I was discussing above, as PR #48
Lets discuss tomorrow