In Jane Street we plan to stop maintaining the compatibility of our open source packages with 32-bit architectures.
This includes everything published on Jane Street · GitHub.
We are not going to deliberately break things, so in the short-term 32-bit builds will keep working, but we’re going to disable the CI that checks 32-bit compatibility, so errors will creep in over time.
The reason we want to do it is two-fold:
We believe there is not much community interest in 32-bit to justify spending effort on maintaining compatibility.
Maintaining the 32-bit CI is burdensome. Among other things, it complicates our work on flambda backend as that needs to co-exist with the 32-bit backend in one source tree.
Afterwards, we aim to keep accepting user-written patches that fix bugs on 32-bit architectures, similar to how we do for Windows and BSD support, but we won’t be able to test those patches ourselves.
If you expect to be affected by this change, please create some noise on this thread so that we have a chance to re-consider the first bullet-point if we are mistaken.
While 32-bit is somewhat on its last legs, there are two glimmers of use which the MirageOS community is interested in:
there is an ESP32 backend to program to microcontrollers (written by @Lortex and presented in OCaml 18). This is not a mainline backend but maintained out-of-tree.
I’m awaiting some RISC-V32 hardware that has been promised pre-pandemic, which again is useful for embedded. Note that there is no 32-bit support for RISC-V in mainline OCaml at present, so this is again a forward looking statement.
None of these are strong objections. Perhaps just keeping Base 32-bit compatible would be sufficient to keep the thread alive for embedded compilation until the hardware world catches up
About jsoo, it used to require a 32-bit switch, but it does not anymore. We use javascript compiled from a bytecode generated as a part of a 64-bit build, and it works great.
I understand the pain and the expense, but distributing Windows 32-bit binaries is normal thing even in 2021. I’m not even sure what percent (1) of Windows PCs are 32-bit, but I am sure that most of the popular Windows applications (Spotify, Telegram, MS *, etc.) are distributed as both 32-bit and 64-bit. The 32-bit situation (2) on Windows is very unlike the situation on desktop Linux (or macOS).
From my perspective disabling 32-bit testing for critical OCaml libraries (yes, Jane Street libraries are critical) is a signal to a sane native application developer to not use OCaml to develop native applications. Granted, the lack of official Windows support is also a strong signal, but I think that is being rectified. I also expect you to not hear much pushback because of survivorship bias (poor Windows support ==> native app developers leave).
For Jane Street in particular, I have Windows 32-bit GitHub Actions (CI) running. If you look at ppx_assert.v0.14.0 you will notice it is failing because the package is expecting a 64-bit function __BitScanForward64. I didn’t file a bug or submit a patch because I think the latest v0.15.x preview fixes the problem. And yes, currently Jane Street doesn’t have Windows CI. But problems like the above will only get worse if we additionally don’t have any 32-bit CI testing.
Perhaps we could simplify to just Windows 32-bit CI and ignore flambda for Windows? Or perhaps do a failures-allowed CI run whenever you coordinate a preview version so that others can see the build failures (like I showed you for ppx_assert.v0.14.0) and can submit a patch before the final release?
Appreciate that you sent this notice!
(1) I know someone will quote Steam 32-bit distribution numbers; that is a biased sample of gamers, not normal Windows PC users.
(2) ~20% or 100 million Windows PCs still run Windows 7, and some unknown percent of those are 32-bit PCs
I really, really dislike to be adding to the pro-32-bit arguments since in general I agree that 64-bit is the way to go but it also means that Jane Street packages won’t be usable on all Raspberry Pi devices anymore.
OCaml is a pretty nice choice for these devices because after the initial switch setup the compiler is fast and the binaries run fast which is great for these compute power-starved devices. But the first Raspberry Pi that supported 64-bit was the RPi 3 and the Pi Zero (W) family are all still 32-bit devices.
According to the 2021 Steam (game platform) hardware survey, 0.3% of Windows Steam users are on 32-bit still. Steam Hardware & Software Survey (expand “OS version” in the table below and add up all of the Windows non-64 bit entries)
In my experience the only reason you need to install a 32-bit version of anything on 64-bit Windows anymore is because something else is shipped only as 32-bit and it interacts badly with a 64-bit thing because of poorly implemented IPC. That is, you want two separate plugins that you don’t have the source to, to play nicely together. Not sure this affects OCaml Windows app devs since they can work around the imposed janky.
Additionally, Microsoft does appear poised to phase 32-bit support out as Windows 11 will be 64-bit only, though will still allow 32-bit binaries.
Repeating this so it doesn’t get lost in the noise.
I don’t think the unsurprising fact that Windows gamers rarely use 32-bit hardware is germane to a discussion about how the vast majority of popular Windows software today is distributed as a) both 32-bit and 64-bit binaries or b) only 32-bit binaries.
Honestly, if Steam is being brought up, why not check the SteamSetup.exe installer? (Cough; 32-bit binary.) Or the steam.exe and streaming_client.exe Steam clients? (Cough cough; 32-bit binaries.) 32-bit binaries are still needed today on Windows. Eventually 32-bit binaries won’t be needed for native (desktop and embedded) apps, but that day is not today. Of course the situation sucks, and I definitely won’t begrudge Jane Street for having to make a hard prioritization choice when today there are probably not that many OCaml desktop/embedded app devs.
js_of_ocaml: we can also compile with the 64bit version, however we need to do quite a bit of hackery due to hash and Marshall, jsoo doesn’t work by default in 64 bits with all OCaml features
windows users like the 32bit version of Coq, as for some reason it is quite faster; should check what goings on with Linux
So I dunno, the jsoo problem can be more critical.
Well, if you want to advocate for important OCaml ecosystem tools supporting Windows 32-bit because you think you’re going to target hundreds of millions of customers with a delivered OCaml binary, and excluding even a few percent of the Windows 32-bit users is leaving millions of potential customers out of your reach, I can’t disagree with the ambition
It’s not about the quantity of customers Specific customers that you are doing contract work for might insist on 32-bit executables because of restrictions on their side. As a contractor you can’t really tell them, sorry, you need to upgrade your machines to 64-bit because I’m using OCaml Jane Street libraries
Of course, there is always the option of not using the Jane Street libraries. Actually, I thought some of the major Jane St libs already don’t support Windows, e.g. Async.
I already did my time in windows land, but 32-bit code can still have some appeal. For code that manipulates mostly large arrays of scalar values, 32-bit code doesn’t offer much. But for code that manipulates pointer-dense data structures, the memory consumption needed in 32-bit mode can be significantly lower than in 64-bit mode. The benefit is not so much due to reduced main memory consumption, but the cache fits more in 32-bit mode than in 64-bit mode, and the available memory bus bandwidth can also sometimes be a bottleneck in 64-bit mode and stressed less in 32-bit mode. So for a lot of bread-and-butter symbolic manipulation OCaml code that runs with a ~3GB or smaller heap, I would not be surprised at all for 32-bit code to be faster. Whenever systems I have worked on could run in either mode, 32 bit has always been faster, sometimes significantly. It is a shame that there isn’t ~48 bit hardware that can still take advantage of practical main memory sizes while making better use of available die area by not needing to wastefully represent the high 16 zeros of pointers over and over again.
But note that I am not objecting to dropping 32-bit support. Using 32-bit mode basically has good cross compilation as a prerequisite. And realistically, nothing I work on can accept the 3-4GB max heap size limit that comes with 32-bit mode.
One vocal user of Coq under Cygwin found the 32-bit version to be faster than the 64-bit version, because of cache effects and the like. But I believe this user is moving to the 64-bit version anyway, because 32-bit Cygwin is being phased out and limits memory usage too much (2 Gb max per process? maybe even less).
The writing is on the wall. Everyone is dropping 32-bit x86 support. Good riddance.
In my opinion, developers should devote their efforts to implement sustainable software. Therefore, basing on a belief to make a part of the machines obsolete is a problem.
On the other hand, if it turns out that only a minority of Jane Street users use 32-bit architectures, using resources to maintain compatibility is obviously undesirable.
The solution would be to make a thorough study of the percentage of 32-bit architectures running Jane Street code.
I don’t have a good grasp of how OCaml is used on ARM platforms.
I believe that ARMv8 (64 bits) is now standard on high- to middle-end phones and tablets (e.g. iPhone, iPad) and is making serious inroads in hobbyist platforms like Raspberry Pi (the RPi model 4 works beautifully in 64-bit mode). This leaves cheap phones and bare-bone boards like the RPi Zero for ARM 32 bits. I’m not sure I really care about these platforms.
More generally: supporting the core OCaml system and its main libraries on 32-bit platforms has a significant cost. Why should the maintainers pay this cost? Are the few users who want continued 32-bit support willing to pay the full cost for this?
Would it be easy to retrofit 32-bit support? If IOT really does begin to play a part in the ocaml ecosystem then the cost of volume 32-bit silicon floorspace can be as much as 4 times less than it’s 64-bit counterpart
I’m not asking you to pay for these costs. I would just like to have a clear understanding of what is going to happen to OCaml on this topic.
First because it can affect my actual code and APIs. For example in some places using ints is inappropriate because of the limits on 32-bit but entirely sufficient if OCaml is only going to be available on 64-bit platforms (an example is representing 32-bit fields of certain file formats).
Second because I want to have a good idea of where I can bring my tools. I have used in the past OCaml on older 32-bit Raspberry Pis to provide interactive terminals for a museum exhibition. If I had to do that project now I would definitively use Pi Zeros, both for cost and form factor reasons.
Specific customers that you are doing contract work for might insist on 32-bit executables because of restrictions on their side. As a contractor you can’t really tell them, sorry, you need to upgrade your machines to 64-bit because I’m using OCaml Jane Street libraries 