It is often believed that Julia somehow performs worse on Windows, while some say the situation is exaggerated. I’d like to open a topic and gather information about this.
2024 April 17th
ThreadPinning cannot be used on Windows, as confirmed by Github readme.
According to @mkitti, closing files on Windows is slow. Maybe partly solved, see update on 2024/4/22.
According to @ufechner7, multi-threaded system image creation only works on Linux.
Because of this issue, which is still open now and not fixed on 1.10.2 according to @nilshg, any package relying on artifacts may be broken on Windows since 1.10 pre-release.
According to my own experience, you need to have Administrator privileges to use PackageCompiler on Windows, because you cannot create symlinks without it. Partly solved, see update on 2024/4/22.
2024 April 18th
StaticCompiler doesn’t work on Windows, as confirmed by Github readme.
2024 April 22nd
As @mkitti mentioned, there is a Windows Developer Mode, which enables symbolic links. The problems is, that turning on this mode needs Administrator privileges itself. So the situation changes from “need admin all the time you wanna create symlinks” to “need admin once to turn on developer mode, then you can create symlinks anytime”. Thus I mark the problem as “partly solved”.
What’s more, as @PetrKryslUCSD mentioned, inside “For developers” there are more options besides developer mode, notably a “dev drive”. It is claimed to optimize the filesystem, so maybe the “slow file-closing” problem can be solved. But I’ve not done any test yet.
This is just Windows, relative to LInux or even WSL in some circumstances. Some file operations are just slower on Windows on order of ~60x slower. This slowness is independent of Julia.
Where Julia can sometimes be involved is when some process tries to do a lot of file operations, which might be fast on Linux but can take some time on Windows.
Yes, but this post aims to offer information to those deciding where to do their work, and I think what should be considered here is the overall performance, whether it is due to a Windows issue or Julia issue.
This topic is in fact somehow a response to this one.
In this case we should also answer the question, if there are some issues where Julia is faster/better/easier on Windows compared to Linux/WSL. Like, a table with Julia features and some kind of rating for columns Windows, WSL and Linux. Hmm… this escalates quickly into something weird… and probably quickly outdated… no, not a good idea.
It’s very possible to use Julia on Windows, at least with 1.9 (or 1.6 LTS…), but this seems to be a l problem, the majors (regression) issue (and only one?):
It can, only on Linux does it do something, it’s a no-op on Windows and other platforms, but doesn’t matter much, since only made for HPC/NUMA and all supercomputers use Linux.
Interesting, a minor limitation (could be fixed?), but not affecting users of compiled programs(?). Also it and StaticCompiler are just packages, not strictly about Julia. Also I believe it’s fixed (at least supports WSL2) and now supports Windows (?), if not always a possibility with any package, and that one is rather special-case, also with lots of limitations on non-Windows.
Edit: I timed the activation and instantiation of DifferentialEquations both on a regular NTFS file system and on the developer ReFS. I found no difference whatsoever, as both took over 14 minutes. So, at this point I have to conclude that there is nothing to recommend the developer mode on Windows for julia users.
Julia 1.10.2 works just fine with windows, but for some packages you need admin rights to make the installation work. (…as a side remark, I would guess that 50% of the Julia users are on Windows, so we better make sure it works.)
EDIT: I forgot to mention that some heavily IT admined machines (which is typically windows) with strict security protocols bump into issues now and then, for instance, with the 7zip program distributed with Julia. But, I guess this is well known.
EDIT: note, this particular issue has been solved, it was due to using an old package.
As of a couple of months, testing of one of my archives on Windows fails with
Building Blink ───→ `C:\Users\runneradmin\.julia\scratchspaces\44cfe95a-1eb2-52ea-b672-e2afdf69b78f\08d0b679fd7caa49e2bca9214b131289e19808c0\build.log`
ERROR: LoadError: Unable to find 7z.exe. Try running `make win-extras` if you built Julia from source.
I just disabled testing on Windows, thinking that the problem would go away. However, students trying to install the code on Windows are encountering the same problem. Is this the artifacts issue mentioned in this thread? I saw that there was an old, closed, issue for Blink.jl, but no open issue.
My archive doesn’t directly use Blink.jl, it is pulled in by another package.
I recommended that students use the Linux layer of Windows, but that may not be appealing to the average Windows user.
Thanks, that solved the testing problem. Blink.jl arrived as a dependency of plotlyjs.jl, which is a dependency of plotly.jl. In this sequence, something was preventing updating to the latest Blink. I just removed plotly.jl as a dep, and updated, and the problem is solved.
As you say it should work, I mainly had that one regression in mind, but there’s also a problem (as can always be we individual packages, this one will get solved, and is not Windows-specific):
