The Julia developers are pleased to announce that Julia v1.7.0 is now in beta, and binaries for v1.7.0-beta2 are available now. You can get them at https://julialang.org/downloads in the “upcoming release” section for macOS (x86-64), FreeBSD (x86-64), Windows (32-, 64-bit), and glibc Linux (i686, x86-64, AArch64, PowerPC). Check out the NEWS file to see what will be new in 1.7.0.
As a beta version, this should not be considered production-ready. Rather, it’s intended to give users, especially package developers, a chance to try our their code with 1.7.0 prior to a full release. Note that 1.7 on Travis, AppVeyor, Cirrus, and (soon) GitHub Actions now refers to 1.7.0-beta2.
Let us know in the issue tracker if you run into any issues. Please note that any bugs you may encounter should be posted there rather than being discussed in this thread to ensure visibility to the developers.
Wow! I did a quick test and this works so much faster and better than previous releases. No more slow jump-ahead for the twister rng and no need to assign a task the rng explicitly to guarantee reproducibility.
Every Task object has a local random number generator state, providing reproducible (schedule-independent) execution of parallel simulation code by default.
Yeah, this is a pretty huge release for multithreaded PRNG usage. Courtesy of chethega (I should probably know his Discourse user name, but I don’t) initially and pushed over the finish line by @jeff.bezanson, with much assistance from @rfourquet. The down side is that the default RNG now produces a totally different stream of values from previous releases, but it seems worth the potential disruption to get such a huge increase in PRNG speed and concurrency.
Personally I think it is totally worth it. I see my c# devs write so much code to deal with this situation.
I think I may have found a bug when running the same code on a single threaded instance in Julia and an instance with 4 cores.
I would think since each task has a local random number generator state, that it shouldn’t matter how many cores I’m using.
The numbers start off the same but diverge. Not sure if coincidence, but the ones that match are all on thread 1.
using Random
N = 10
Random.seed!(1234);
# Any because I was experimenting with gathering task local info not just doubles.
x = Array{Any}(undef, N)
Threads.@threads for i in 1:N
x[i] = rand()
end
Different RNGs per thread means different random numbers per thread - the collection is partitioned and subsequently each thread fills its respective section with random numbers from its RNG.
Glad to hear it! We thought so too. We’ve also been warning people for a long time now that the default PRNG sequence should not be relied on to be stable, so hopefully those warnings have helped a bit. My guess is that there are packages (and other code) that are relying on this for tests and with this breakage they will hopefully switch to using StableRNGs.jl which can be relied on to produce the same PRNG sequence forever.
The number of tasks that @threads generates depends on the number of threads. If you did something like this instead, you get the expected result:
for i in 1:N
Threads.@spawn x[i] = rand()
end
This produces the same values no matter the number of threads. This is not what the @threads macro does, however: it splits the range of the for loop into as many blocks as you have threads and then creates a task for each of them. This pattern is much more efficient because creating tasks is not free. It’s quite cheap but not free.
I think this is the closest thing before proper 1.7.0 release, but it doesn’t get picked up by the docs version selector dropdown for some reason https://docs.julialang.org/en/v1.7-dev/
https://docs.julialang.org is the documentation for every Julia 1.X. Documentation is not built for beta releases, but once there is a release candidate (rc) that should show up in the selector.