About Julia's development policy regarding Windows

People seem to be piling on the OP for, from what I understand, their issues with simply running a small script that they got from a Juliacon video. I also found the OP gave suggestions and wanted to have a fair bit of discussion. Clearly, the OP is new to the Julia community including its development processes and the nature of packages. The OP is is using discourse as a means to interact with the community, which is perfectly fine. The OP should not have to learn how to navigate Github simply to point out their issues, their suggestions, and even their gripes. I am not really sure why the general sentiment of the replies were ā€œyou are doing it wrongā€ instead of actually helping the OP (as that’s what I assume the intent is by engaging in the post in the first place).

This is clearly unhealthy and also is not the first time I have noticed this. As the language grows, there are going to be more permutations on how to do certain things. There are going to be folks who install Julia using binaries and have PATH issues because they found the install instructions on an outdated blog post. There are going to be folks who try to use newer features on older versions of Julia. There are going to be folks who install a newer package version, but hit an open bug from several versions ago. When these folks are frustrated that their tiny scripts are just erroring out and post on this forum, we should avoid the sentiment of blaming them for their issues. Rather, acknowledge that as the language grows, things are going to be fragmented and try to address their concerns.

17 Likes

Maybe let’s not explode this thread even further by engaging in this meta-discussion (unless one of the moderators wants to split it off)

2 Likes

With respect to release process, there’s a difference between Julia and your experience with FreeCAD: FreeCAD is an application that produces products divorced from code, whereas Julia is a foundation for other code. Thus while FreeCAD betas target users, the core audience of Julia betas are developers. The beta period is a time for developers of key packages to try out the upcoming release and report/fix any issues. In general, people who are just Julia users should wait until release.

Why is this difference important? One of Julia’s strengths is that much of Julia is written in Julia, and that means that many applications dive deep into Julia’s internal representations. For example, the debugger based on JuliaInterpreter is a package, not part of Julia proper. However, as a debugger it needs to work with Julia’s internal code representations at an early stage of the compilation pipeline. Such internals are explicitly not guaranteed to be stable, and really can’t be if we want to see Julia continue to improve. (Many of the improvements from 1.0 to the present would not have happened if we required the internal representations to be fixed.) As a consequence, such packages often require extensive updating in preparation for a new release.

Of course, the vast majority of packages aren’t affected by these internal changes: a well-developed package devoted to certain linear algebra operations, for example, should not require any updating to work on the latest release. But a lot of the tooling that sophisticated developers use to write such packages are affected by changes to the internals.

So think of a beta as a call to action by experienced Julia developers to start kicking the tires. It’s definitely not intended for the audience you describe.

22 Likes

Is this really true? I can imagine 1.11 being slower in itself, but I don’t think anything in the PackageCompiler process should use threads (except a part of the very last step in outputting the sysimage and I am not sure that even uses the number of julia threads). If you turn off threading, does 1.10 also become 40% slower?

Could you explain what part of PackageCompiler you think gets faster with your threads environment variable?

I just tested myself and didn’t notice a difference (on 1.10):

# Without threads
julia> using PackageCompiler

julia> ENV["JULIA_NUM_THREADS"]
"1"

julia> Threads.nthreads()
1

julia> @time create_app("examples/MyApp", "MyAppCompiled"; force=true)
...
150.910366 seconds (1.92 M allocations: 151.919 MiB, 0.01% gc time, 0.28% compilation time)

# With threads
julia> using PackageCompiler

julia> ENV["JULIA_NUM_THREADS"]
"10"

julia> Threads.nthreads()
10

julia> @time create_app("examples/MyApp", "MyAppCompiled"; force=true)
...
148.749071 seconds (3.82 M allocations: 291.721 MiB, 0.03% gc time, 0.28% compilation time)
4 Likes

PackageCompiler gets stuck with multiple threads for some cases (e.g. `create_app` never finishes on Julia v1.11.1 when `JULIA_NUM_THREADS` is set Ā· Issue #990 Ā· JuliaLang/PackageCompiler.jl Ā· GitHub and PackageCompiler never ends on julia 1.11.0 with --threads=6 Ā· Issue #963 Ā· JuliaLang/PackageCompiler.jl Ā· GitHub), so using a single thread becomes the workaround for those. Don’t know about the performance impact in general, though.

Okay but that was the whole question.

2 Likes