Open jmason42 opened 5 years ago
After doing some more tests with numba
I was getting results where the jit compiled code was taking longer than the uncompiled code (10s vs 25s for the same simulation). I will make a new issue for it, but for now I am leaning to keeping this uncompiled, both for this reason and to avoid nondeterminism with RNG.
That's troubling. If you have a working example, I can poke around. It's possible that it was only compiling the already fast parts.
Yeah I actually removed the numba parts, but it should be easy enough to put back in to test. I also had a few problems with compilation, for instance the list comprehension threw some kind of "This error should not happen" deep in the numba code, but works with map
? Kind of funny. Now that I think about it I should have written all this down, but I was moving fast and just stripped it out instead with the intention that I would try it again later.
A separate resource for Numba friction points would be tremendously helpful. There's not a lot out there.
We need all implementations to be deterministic. With any sort of compiled approach (JIT, Cython) this is challenging.
It's particularly tricky to support determinism with the single-step approach (as opposed to evaluating to some time point) with compilation since jumping in and out of compiled code while maintaining a PRNG state is difficult or impossible. I'm inclined to suggest that the step-based procedure should be handled via a class or generator function, while the run-until procedure should be handled by a separate function entirely, with the expectation that the two will not lead to the exact same results.