Is anyone using 32-bit Julia on Windows?

I don’t see much reason to keep that dying platform around, and think it would help it it were retired (but not (yet) 32-bit Linux).

I see work on Julia seemingly blocked on it (getting rid of libm, otherwise done, or almost done).

And I’m not sure, maybe it’s slowing down very important work like this:

I’m at least reading through (32-bit) CI logs that maybe should just be dropped (it also takes resources to generate them, you can easily wait 5 hours for them generated, and 6 hours for the awesome PkgEval, which would be “sequentially, 26 days” of work, so seemingly using 104 CPUs so we don’t want to do useless work). Would you rather want faster development of Julia or keep 32-bit?

Likely 32-bit Windows would still work, maybe not perfectly(?), and just no longer a tier 2 platform.

Note Windows 11 doesn’t support 32-bit CPUs (though does support 32- and 6-bit (Julia) programs).

Only Windows 8.1 (and 10) support 32-bit CPUs, already out of mainstream support, and extended support only until January 10, 2023. For Windows 10 “Mainstream support for all editions except “LTSB/LTSC” variants ended on October 13, 2020 and extended support continues until October 14, 2025”. The dropped support applies to 64-bit too, and maybe it’s actually sooner for 32-bit?

Windows Server no longer supports 32-bit, Windows Server 2008 was the last version to do it. Though you can pay extra to keep it around (and “Azure Virtual Desktop” isn’t relevant to Julia): “ESU (Extended Security Updates) program (free for Azure Virtual Desktop users).[5] This program allows volume license customers to purchase, in yearly installments, security updates for the operating system through at most January 10, 2023 (January 9, 2024 for Azure customers)”.

3 Likes

I know you are talking about windows specifically but just want to point out that a lot of small cheap SBCs such as Raspberry Pi are still using 32 bit so the Linux version makes sense.

1 Like

Build and test on 32 bit is really slow.

MSYS2 v.s. Cygwin build and test time

Shell env MSYS2 Cygwin MSYS2 Cygwin
toolchain mingw64 mingw64 mingw32 mingw32
arch x86_64 x86_64 x86 x86
Build . . . .
Sysimage built/s 55.9 55.9 87.7 85.9
Precompilation/s 148.9 147.1 691.6 672.4
Pre–Generation 115.4 113.9 440.5 433.2
Pre–Execution 33.5 33.2 251.1 239.2
Output sysimage/s 150.6 149.1 156.6 155.7
Test . . . .
Overall 27m02.3s 26m27.7s 70m14.0s 72m15.3s
LinearAlgebra/triangular 10m58.9s 10m52.0s 14m35.1s 14m07.8s
LinearAlgebra/addmul 9m19.5s 9m07.8s 12m05.8s 6m28.2s
intfuncs 10.1s 10.0s 12m05.4s 12m43.9s
bitarray 3m40.3s 3m42.3s 23m17.4s 24m01.3s
Profile 30.8s 32.1s 34m35.5s 38m22.2s

full test log:


So, you mean move Win i686 (32-bit) from “tier 2” to “tire 3”.

Do we want to keep the 32bit CI?

1 Like

I wonder what is the number of Windows 32-bit downloads?

2 Likes

To tier 3, or 4 or not offered at all. I don’t really care, whatever makes sense. I don’t even use 64-bit Windows, though I want that kept. :slight_smile:

Right, why I want it kept. I’ve not used 32-bit, except downloaded by accident (then 32-bit snap Julia, it’s now 64-bit), and also intentionally for some testing. Might apply for some Win32 too, or just downloaded by mistake, so I’m curious about the download numbers too.

I get a feeling of deja vu and am certain I’ve written this before.

I have exactly one use case for 32-bit Julia on Windows and that is to ccall into a proprietary binary-only 32-bit dll needed to communicate with a piece of expensive hardware. That library will never be updated to something sane although the hardware might break at some point. But I also have no need to update to new Julia versions for this use case.

1 Like

So that means you DON’T want Win32 supported forever (just for you)? But possibly needed for others? It would still be supported with Julia 1.6 LTS, at least until it’s no longer LTS… and unsupported Julia versions will keep working…

Since this could be a problem for people (in your situation, and we certainly want Julia to work for “expensive hardware”, I suppose, for science) into the foreseeable future, I was curious if there’s a workaround, but it means having a different 32-bit process (that would then not be Julia, or older Julia LTS, you think could be fast enough; for you?):

You’ll need to have the 32-bit dll loaded into a separate 32-bit process, and have your 64 bit process communicate with it via interprocess communication. I don’t think there is any way a 32-bit dll can be loaded into a 64 bit process otherwise.

There is a pretty good article here:

Accessing 32-bit DLLs from 64-bit code

  1. Host the COM component out-of-process using the COM surrogate DLLhost.exe. This will make calls to the COM server much, much slower (they will now be interprocess Windows messages instead of native function calls), but is otherwise transparent (you don’t have to do anything special).

You can look at the PkgServer statistics, they’re public: Announcing: package download stats!

1 Like

Thanks, I did take a look at julia_systems.csv, the Win32 downloads (excluding CI downloads), they are not nothing but on the decline, are there are e.g. 741 users for 1.7.2 (0.94% of Windows users for that Julia version) vs. 78370 for Win64 and 32699 for Apple:

I’m plotting request_addrs column (is request_count the right column to plot (seems too high) or successes which is lower?)

Most frequent it (single version, not cumulative):

x86_64-w64-mingw32-libgfortran5-cxx11-julia_version+1.7.2 at 78370 (well CI number is highest 572236 for a single Linux version)

or rather unbelievable 10891633 user, non-CI, request_count for x86_64-linux-gnu-libgfortran5-cxx11-libstdcxx29-julia_version+1.7.2 highest

I wasn’t expecting 1.10:
x86_64-apple-darwin-libgfortran4-cxx11-julia_version+1.10.0

Surprisingly I did see a download for RISC-V CPU: riscv64-linux-gnu-libgfortran5-cxx11-libstdcxx30-julia_version+1.9.0