Janet on the x32 ABI Used 8 to 30 Percent Less Memory in Four Tests, With Speed Within 12 Percent

Compile the Janet language for the x32 ABI and four benchmark programs use between 8 and 30 percent less memory, with run times between 11 percent faster and 12 percent slower. That is the finding of Alex Alejandre's write-up, published in October 2026 under a "25% Less RAM" title that the post's own summary softens to 21 percent.

The x32 ABI keeps the 64-bit instruction set but shrinks pointers to 32 bits. The cost is a 4 GiB address space per process.

What was measured on Ubuntu 20.04

Alejandre built Janet with -mx32 on Ubuntu 20.04 LTS. He edited src/include/janet.h so Janet would not pick its 64-bit value layout on x32, and disabled FFI support.

The four tests, with time and peak memory for the 64-bit build against the x32 build, are below.

1. Records, 64-bit138.4 MB
2. Records, x32126.9 MB
3. Tree, 64-bit50.3 MB
4. Tree, x3235.4 MB

Source: Alex Alejandre, Janet on x32, accessed 2026-10-07

Test	64-bit time / memory	x32 time / memory
Words	0.60 s / 41.8 MB	0.67 s / 31.9 MB
Records	6.50 s / 138.4 MB	5.80 s / 126.9 MB
Tree	1.39 s / 50.3 MB	1.43 s / 35.4 MB
Parse	3.35 s / 58.5 MB	3.13 s / 44.4 MB

Working from those figures, memory fell 24 percent on Words, 8 percent on Records, 30 percent on Tree and 24 percent on Parse. Two tests got faster (Records and Parse) and two got slower (Words by 12 percent, Tree by 3 percent). The author's own summary is "21% RAM reduction (8-32% range) with equal speed."

Why the saving is smaller than it could be

Janet packs each value into 8 bytes by nanboxing. Alejandre calls it a "worst case scenario" for x32 because the value size stays 8 bytes either way and only pointers inside structures shrink. A pointer-heavy heap would gain more.

A separate run on Arch Linux using -m32, which is 32-bit x86 and not x32, shows what happens without the 64-bit instruction set: 20 million array elements took 2.83 s and 1.4 GB on 64-bit, and 4.64 s and 1.1 GB on 32-bit. Less memory, but a much slower run.

The post also relays a deployment report from a person it calls Hailey, who cut a Mastodon install from 650 MB to 350 MB on x32. We could not check that figure.

Why almost nobody can run it

x32 needs the kernel option CONFIG_X86_X32_ABI. The post says Ubuntu 20.04 supports it, Arch does not compile it in by default, and Debian disables it unless a boot flag is set. Windows and macOS have no equivalent.

Wikipedia's x32 entry says the ABI was merged for Linux 3.4 and glibc 2.16 in 2012. It cites a 40 percent gain on the SPEC CPU 2000 181.mcf test and 5 to 8 percent on average across SPEC integer tests, with no floating-point advantage. It also notes a December 2018 discussion about deprecating x32 that had not led to removal as of April 2023.

Distributions with an x32 port or build option include Debian, Gentoo, the Yocto Project and T2 SDE.

What a language author should take from it

A small runtime that already boxes values is a weak test case, and it still saved memory. Our Python 3.15 benchmark chased wall-clock gains, while Gleam 1.19 went after build time. x32 is the quieter option, trading address space for footprint.

The decision for a language author is whether a 4 GiB ceiling per process is acceptable for the workloads the runtime is meant for. For scripting, tooling and small services it usually is. For anything holding a large dataset in memory it is not.

Alejandre's tests cover four small programs on one older Ubuntu. Whether the saving survives on a long-running service is not shown. The next step would be repeating the run on a current kernel with a pointer-heavy workload.