Jane Street packages: dropping support for 32-bit

[dinosaure]

@xavierleroy

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?

I’m not really sure about that. Since we have a CI which checks for us our tests on 32-bits platform, we have a support about such platform for MirageOS projects. As I said into another thread and in the way to support IoT, 32-bits platform is a common platform.

About the work, I want to follow @dbuenzli and say that it’s not hard to make something which works on 32-bits platform as far as you don’t use the Obj module or implement something on top of some strict assumptions (like my int can contains, at least, 32 bits - and even such case can be fixed). We discovered some bugs due to the 32-bits platform mostly on C stubs.

On the OCaml side, and mostly because we don’t want to implement some fancy extra micro-optimizations over some obscure representations into the caml runtime and we prefer to make something portable (in the MirageOS spirit), we did not get weird bugs or some situation which imply that we need to rewrite the whole code. Most of the times, it’s because we did not have something to check for us the 32-bits support - now, we have one.

Note that such needed work was done too about big-endian support - and of course, we got some bugs too when we tried to use our libraries on this platform (s390x) but, again, the series of patches was really small if we compare to the MirageOS eco-system.

From this experience, I consider that we don’t have a huge cost to maintain libraries on 32-bits platform and, as @dbuenzli, I’m pretty happy to have the possibility try to flash a MirageOS into a RB Pico/ESP32 chipset, etc.

NOTE: this is my opinion but most of the times, when we have something which can not work on many platform, it’s because we want to integrate a micro-optimization. On this question, it’s not sure that such micro-optimization which, most of the time, take the advantage of the representation of an integer has a huge impact. Don’t let me wrong, I can understand that, in some special (and very specific) cases, these micro-optimizations can have an impact but, as far as I can say, they consider systematically a specific (really constrained) context (the platform, the state of the GC, etc.) and it’s on the opposite on what we try to do in MirageOS where we are mostly aware to provide something which should work anywhere (and it was a initial reason about why we choose OCaml and its runtime to make unikernels ).

[xavierleroy]

@dbuenzli

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.

First: the latest Raspberry Pi Zero is a 64-bit platform (Raspberry Pi Zero 2 W: 5x faster than the original for $5 more | Ars Technica).

Second: don’t be cheap. Choose hardware that matches the software you want to run, not the other way around. Hardware adapts faster than software to your needs.

[dbuenzli]

@xavierleroy

First: the latest Raspberry Pi Zero is a 64-bit platform (Raspberry Pi Zero 2 W: 5x faster than the original for $5 more | Ars Technica).

It wasn’t when I wrote the message :–)

@xavierleroy

Second: don’t be cheap. Choose hardware that matches the software you want to run, not the other way around. Hardware adapts faster than software to your needs.

It’s not about being cheap, it’s about trade-offs. Budgets are limited and the software I want to run matters very little to clients. They care about an impeccable end result and costs.

There’s always a lot of things to balance in hardware projects and pennies saved there can always be invested in other aspects, e.g. better displays, better sound system, better sensors etc.

If you have something that you can reuse or that is cheaper, has a better form factor for the installation, and is sufficient computation wise it’s difficult to justify going for something else “because I want to use OCaml”.

[MaxHaydenChiz]

Powerful microcontrollers and ASIC IP are still 32-bits, as are most soft CPUs. It’s wrong to assume that personal computers are remotely representative of all computer usage. People wouldn’t be using 32-bit (or sometimes even 8-bit) microcontollers if those costs didn’t matter in some use cases. RISC-V wouldn’t have a special 16-register only model if there weren’t problems with even an implementation of their baseline 32-bit spec.

Furthermore, there is a code quality benefit that even people exclusively using 64-bit x86 will benefit from. I still regularly find bugs in low level code when I compile 32-bit vs 64-bit (as well as for different platforms entirely).

There are lots of embedded applications that need 32-bit support and will for the foreseeable future. So, instead of claiming that 32-bit is dead, that everyone should just always use 64-bit, or whatever, I think the question should be, “how important it is for OCaml to be easy to use in typical 32-bit environments like IoT, and does the costs of maintaining this particular code justify the benefits of having the language able to support that use case?” On the latter, I’d say that “you have to use a completely different standard library than what you are used to if you want to use OCaml for IoT” is a pretty strong indicator that IoT is a second-class citizen.

Not saying one way or the other. Just objecting to the idea that everyone can / should move to 64-bit for every conceivable application.

If you want a solid answer, you need to ask the people doing work in resource constrained environments since they are the ones directly affected.