epinowcast / hashprng

Hash-based Matching Pseudo-Random Number Generation
https://hashprng.epinowcast.org/dev/
Other
2 stars 0 forks source link

performance tests #2

Open pearsonca opened 1 year ago

pearsonca commented 1 year ago

Worthwhile to add some benchmarking stuff?

pearsonca commented 1 year ago

Screenshot from 2023-08-01 17-31-56

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.

seabbs commented 1 year ago

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})
})
seabbs commented 1 year ago

Also worth checking out bit64?