performance tests about hashprng HOT 3 OPEN

Overall, adding HBM is ~ an order of magnitude increase in run time - that's way above theoretical expense. I'd like to get it to sub-order of magnitude multiplier (so < 5x) for the draws component. Simulations will vary in how much of their computational component is RNG, so in general the actual multiplier will be less than that due to RNG-only, but ~10x is still too high.

As shown in screenshot above, a few things that are a bit hot. We can do better on the hashing step (switching to a faster hashing algo should trim that portion 2-3x), but that won't speed up converting things to raw array to feed.

Any ideas on how to approach that latter problem?

We could do something like restrict ... inputs to integers only, then eliminate the writeBin step. I'd prefer to keep the user-side flexibility of using whatever, but might have to sacrifice that if we can't finding a sufficiently performant way to offer it.

from hashprng.

Unless I am missing something the Reduce call is a slow choice vs other options.

iterations <- 1e3
within_its <- 1e3

system.time({
  Reduce(c, lapply(1:iterations, function(i) {1:within_its}))
})

system.time({
  unlist(lapply(1:iterations, function(i) {1:within_its}))
})

system.time({
  sapply(1:iterations, function(i) {1:within_its})
})

from hashprng.

Also worth checking out bit64?

from hashprng.