Is anyone using 32-bit Julia on Windows?

General Usage
1

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
2

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
3

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
4

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

2 Likes
5

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.

6

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.

2 Likes
7

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).
8

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

1 Like
9

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:

mynd
mynd1000×485 78.7 KB

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

10

I noticed that conda-forge dropped support for 32-bit Windows:

Anaconda’s miniconda has not been updated for 32-bit Windows since Python 3.9 (no Python 3.10, Python 3.11 releases)
https://docs.conda.io/en/latest/miniconda.html

SciPy apparent dropped 32-bit Windows support as of version 1.9.2 in October 2022:

I think we should start considering an end-of-life plan for 32-bit Windows support. The first question might be when support degrades to Tier 2 from Tier 1.

5 Likes
11

When we migrate to using UCRT, we may only be able to support x86_64 if we don’t want to add support for libc++.

MSYS2 env set

now

  • mingw32: gcc-i686 + msvcrt + libstdc++
  • mingw64: gcc-x86_64 + msvcrt + libstdc++

use new UCRT

  • ucrt64: gcc-x86_64 + ucrt + libstdc++

or UCRT + libc++

  • clang64: llvm-x86_64 + ucrt + libc++
  • clang32: llvm-i686 + ucrt + libc++

NOTE: Cygwin doesn’t seem to support UCRT at the moment.

1 Like
12

Not a single Raspberri Pi model is x86, they’re all ARM. From the Supported Platforms section of the Downloads page, I see ARMv8 64bits is Tier 2 and ARMv7 32bits is Tier 3, on Linux. So already not Tier 1. They do not enjoy the 32 bits x86 Windows (or Linux) Tier 1 status.

1 Like
13

One note thst I saw suggested that ARM64 Windows users could use 32-bit Windows binaries via emulation

14

I was actually thinking just that, and I feel sorry for those who do active development on 32 bits, just because their hardware has to be old enough that compilation times are beyond painful. I have a 3 year old decent mobile amd64 CPU and I feel like upgrading to a recent top of the line CPU just for Julia.

15

Python still supports 32-bit, and while they do (maybe for good reasons, a lot more Python out there, possibly e.g. in 32-bit games), that’s not an argument I’m making that we should to it too, even though we compete with them. I see it’s still tier 1 for them:

CPython’s Windows support currently follows Microsoft’s lifecycles.

i.e. I believe that means they want to support 32-bit Windows, thus 32-bit CPUs, as long as Microsoft does. I’m sure they want to drop it soon enough. It makes no economic sense for us (or them) to support 32-bit Windows, by now only Windows 10.

Windows 11, and Server, only support 64-bit. 8.1 is now out of support.

Supporting 32-bit x86 (IA-32) is about supporting older than 10-year-old computers (in case of Atom, some were only 32-bit, i.e. Bonnell from 2008, discontinued in 2013), or 18-year-old CPUs (non-Atom). Intel supported 64-bit x86-64 in “May 25, 2005; 18 years ago” with Pentium D/Netburst, “Discontinued July 13, 2010; 12 years ago.” AMD introduced x86-64 earlier in 2003.

I believe you can no longer buy new (or used?) 32-bit Windows computer, i.e. with a 32-bit CPU, or 64-bit CPU (but 32-bit Windows installed, why would you?).

All non-LTSC versions:
Supported until October 14, 2025, with the latest feature updates.

Though Windows “IoT: Mainstream support until January 12, 2027 and extended support until January 13, 2032”. We don’t really need to support Windows IoT.

https://www.microsoft.com/en-gb/software-download/windows10ISO

64-bit or 32-bit processor (CPU). You’ll create either the 64-bit or 32-bit version of Windows 10 that’s appropriate for your CPU.

The requirements:

RAM: 1 gigabyte (GB) for 32-bit or 2 GB for 64-bit

The cheapest computer at $87 and $176.69 Amazon came op with for 32-bit search were actually 64-bit:

Fanless Mini PC Win10,Intel X5Atom Z-8350-Dual Band WiFi AC-64-bit Win10/UBuntu 16.4-HD Graphics 2GB+32GB Mini Desktop Computer-HDMI/VGA 1000Mbps LAN Support Dual Screen (Without OEM Key)

HP EliteDesk 800 G1 Desktop, Intel Core i7 4770 3.4Ghz, 32GB DDR3 RAM

Cheapest on Ebay at $38.71, I think but actually not sure, it’s 64-bit:

Acer Aspire SW5-012 - Windows 8.1 32 bit, 64 based processorRam 2gbOpens in a new window or tab
Pre-Owned

1 Like
16

Hmm,

Yes, ARM64 can emulate 32-bit Windows binaries (a good thing), but I think your point is they don’t support emulation of 64-bit x86-64. That may be true, and while they could in theory, in either case you cant to recompile. ARM64 is tier 1 for macOS, not yet for Julia ARM64 on Windows (it’s tier 2, already mostly working?). It seems we can and should soon enough. We at least would want to do that, as opposed to

Are Amm-based Windows computers common enough for us to worry about yet? And it’s not that 32-bit Windows Julias will just stop working. Older, including Julia 1.6 LTS will.

If Julia 1.10 (or 1.9) will be LTS, which seems likely, I would rather NOT have it support 32-bit Windows, i.e. not to commit to that for, e.g. 3 years. If we have not lowered from tier 1 by then, we at least could condition the LTS to exclude it.

17

Is it purely to keep on supporting very old code though? Meaning it’s an issue Python has (don’t want to break or stop supporting some 2010 code), but Julia doesn’t really have?

18

That’s my guess, yes. Python was at some point 32-bit only, but Julia was 64-bit from the start (and 32-bit also available). I don’t know of a single Julia package that is 32-bit only, more likely some are 64-bit only, because of a bug not making then work in 32-bit too.

In some very exceptional case you may want to call some non-Julia 32-bit code, and that will still be possible if that code runs in a separate process. On Linux, in-process, all the code needs to be either 64-bit or all 32-bit, so if you have e.g. a 32-bit only C library, then you would want 32-bit Julia, and I support keeping 32-bit Julia for Linux around (we have an actual 32-bit Windows libc problem that doesn’t apply to Linux). This might not be a strict restriction in Windows, I’m not sure.

19

The problem I am seeing is that our scientific and numeric computing couterparts on the Python side are dropping support for important packages. This means that eventually our Julia frontends for those underlying libraries will begin to degrade on that platform.

20

As I understand it, new Windows versions are all 64-bit after 2020, so there are no new 32-bit versions being given to computer manufacturers, who are independently phasing out their 32-bit processors.

Windows 11 on ARM recently introduced 64-bit Windows support, I think Windows 10 on ARM is still only 32-bit emulation, a little inconvenient with the phasing out process now but apparently it’s what was in demand.

This is in the context of personal computers, though, embedded systems and microcontrollers seems like its own can of worms when Julia gets to the point it can fit on them on a regular basis.