Julia v1.7.0-beta2 is now available

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.

88 Likes

Awesome! How do I use it with GitHub actions? Just 1.7 as version is not working for me right now: workflow

Quoting from README of the setup-julia workflow:

^1.3.0-0 is a caret version range that includes all pre-releases. It matches all versions ≥ 1.3.0- and < 2.0.0 .

So you want to do

"^1.7.0-0"
9 Likes

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.

5 Likes
df[(remembering .> parens) .& (was .< crucial)] #v1.6

df[this .> is .&& absolutely .< brilliant] #v1.7

Thank you @mbauman for #39594.

17 Likes

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.

15 Likes

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

One thread:

julia> x
10-element Vector{Any}:
 0.8521319181373054
 0.7689799548530378
 0.6243499745554029
 0.3293649906351931
 0.9990226080289056
 0.24044820241363107
 0.0192236627448511
 0.6335674481579363
 0.7846641780713622
 0.25749532080682724

Julia -t 4

julia> x
10-element Vector{Any}:
 0.8521319181373054
 0.7689799548530378
 0.6243499745554029
 0.4129780578067782
 0.5739657632171419
 0.9755932386001536
 0.6278063483588922
 0.9986465688348583
 0.5105042328844386
 0.7418532936197424
4 Likes

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.

2 Likes

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.

5 Likes

I thought because the Tasks where given their own local random number generator state in 1.7 beta, that the number of threads wouldn’t matter.

1 Like

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.

3 Likes

10 posts were split to a new topic: What are the current plans regarding a new LTS Julia version?

@foobar_lv2 ?

2 Likes

This post was flagged by the community and is temporarily hidden.

Ah yes! I forgot that was his user name here. Sorry, @foobar_lv2!

2 Likes

Hope Cxx will support it!

5 Likes

Is there documentation for this version?

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/

2 Likes

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.

3 Likes

Meanwhile I think it is worth to check the [History](“julia/HISTORY.md at master · JuliaLang/julia · GitHub” julia/HISTORY.md at master · JuliaLang/julia · GitHub).