JuliaLang/julia — pull request #8832 by rfourquet (2014-10-28 11:41:13+00:00)
Title: dSFMT: use fill_array_* API instead of genrand_* API

This is the same as PR #8808 (but on a branch in the main repo) updated to work also with the global RNG, which becomes an instance of `MersenneTwister`.

Consequently, `rand[!]` functions involving the global RNG become faster when filling arrays of `Float64`, but slower when producing `Float64` one by one (because of the use of a global Julia object), and, worse, when filling arrays of other types: the problem is that there is a call to `rand(T)` at each iteration. The solution is to add a `rand!{T}(mt::MersenneTwister, A::Array{T})` (which implies having `rand(mt, T)` methods) and have `rand!{T}(A::Array{T}) = rand!(GLOBAL_RNG, A)`. So should I do this here, or leave that to (a re-write of) PR #8380 (hence keeping the current PR minimal)?

WRT points raised by @ViralBShah in #8808:

* there is already a one line test concerning issue #6573, I'm not sure what other test I could add. Also should the wrapping of `dsfmt_genrand_*` functions in dSFMT.jl be removed, or left for users who know what they do (a warning could be added in this file)?

* "make sure that Rmath-julia is also consistent with this" : I don't know what to look for.

In order to preserve previous performances when generating unique values or filling small arrays, I had to add a bunch of `@inline` annotations (I'm not sure that all of them are strictly necessary though), which I find noisy, what do you think?
What about exporting a function `globalRNG` which returns the GLOBAL_RNG object?