How important is 32-bit testing?

[penelopeysm]

Generally, I find we spend a disproportionate amount of developer time trying to track down issues in 32-bit CI. These are:

• not reproducible locally because none of us have 32-bit systems, so the only way to test is to run code on GitHub runners;
• often difficult to reproduce even on GitHub runners because they involve very fundamental errors e.g. segfaults or OOM errors. The latest one is here: https://github.com/TuringLang/DynamicPPL.jl/actions/runs/13244193116/job/36993574461?pr=806

Given that it's 2025 and most computers are 64-bit, I'm wondering whether it's really worth our effort to keep testing on 32-bit? (Consider also that 32-bit systems are limited to 4 GB of RAM, which by today's standards is pretty small — so it seems to me that most computers one might want to run Turing on should be 64-bit — although I am keen to hear counterexamples!)

[yebai]

I am happy to drop 32-bit support because the effort required outweighs the benefits.

[penelopeysm]

At today's meeting (17/2/2025) we decided that it's ok to drop 32-bit testing. The reasons are:

1. 32-bit systems are rare. Some GPU code may require usage of 32-bit floats but that's different from the underlying system architecture from
2. When 32-bit CI fails, we either (1) spend a lot of time trying to figure out why, or (2) ignore it. The former is a time sink, the latter implies that we don't really care about the result, in which case we shouldn't test it.
3. The only genuine 32-bit bug we have found through CI was actually in Mooncake Missing rrules on x86 Julia for matrix distributions compintell/Mooncake.jl#289, and we consider the chance of finding a 32-bit bug which is (1) easily reproducible; (2) actually affects users; and (3) is actually caused by a bug in Turing (vs. a dependency or Julia itself) is vanishingly small.

Moving forward we'll:

1. Explicitly specify in the docs that 32-bit support is not guaranteed.
2. We could even consider adding a warning when Turing is loaded. (Although this does raise a question of whether we should also do this for e.g. untested Julia versions?)
3. Drop CI testing.

[mhauru]

I think it's a good idea to mention in our docs that Turing.jl is untested on 32-bit, but if someone comes to us with a bug report about 32-bit issues I don't think we necessarily have to say "this is unsupported, you are on your own". Not testing for something because it's cumbersome and probably not very helpful can be distinct from dropping all support, i.e. I view this as a right for us to ignore any 32-bit issues, but we can always be magnanimous about it if any come up.

[penelopeysm]

I'm just going to unilaterally do this, because we all discussed it quite democratically at our meeting already and it's just boring chore work to update CI + the docs that probably doesn't need review.

[yebai]

I'd suggest that we keep the CI tests on X86 for AbstractMCMC, and MCMCChains if it doesn't incur extra maintainance burden. These libraries have a much narrower scope so should be less volunerable to edge-case issues we see in Turing.jl.

[penelopeysm]

ok, will revert

[penelopeysm]

Ok that might be it. There's still AdvancedPS, EllipticalSliceSampling, and Libtask, but I reckon those can be left alone too. So this is done 🎉