\n\nIt’s possible to save a dramatic amount of memory (close to half for programs with pointer heavy heaps) and also speed up programs by a modest amount (by way of more data fitting in cache) by using 32 bit pointers on 64 bit systems.
\nThe Linux x32 ABI lets you do just this, but it’s tragically underused and overlooked. It’s disabled by default on Debian (though you can enable it with a boot flag) and not even compiled in on Arch Linux. Most software compiles just fine for x32, but there isn’t much packaging for it so you do have to compile nearly everything yourself.
\nI experimented with deploying mastodon on x32 and it cut the app’s memory usage from 650mb to 350mb. There’s so much potential here, but the work is mostly of the thankless coordination and communication type and I don’t have the time or motivation to push it forward myself. - Hailey
\n
Janet libraries like Spork supply their own build flags, but we can hijack them with a fake cc which starts the real one with the necessary -m32 -msse2 -mfpmath=sse flags. I modified the beginning of my default Janet build script:
#!/bin/sh\n\n\nTARGET="/janet32"\nJANET="/bin/janet"\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\nEasy enough! Now let’s try it!
\ntl;dr: 20% memory reduction, 50% slower
\nSee the Scripts and Results
\nThis is on cachyos (arch, btw) with lib32-glibc lib32-gcc-libs. Adding this to a build script forces libraires like spork to build at 32 bit too!
\nFor mem.janet:
(let [live @[]]\n (for i 0 2_000_000\n (array/push live [i (+ i 1)]))\n (gccollect)\n (print (length live)))\nNote, these use Fish and I don’t want to rebuild my site with other language support:
\n\n\n\n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n\n\n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \nI added a 0 in the test
\n\n \n\n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n\n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \nFor e.g. declarative-dsls/tests.janet
\n \n \n \n \n \n \n \n \n \n \n\n\n\n \n \n \n \n \n \n \n \n \n \n \n \n \nAs Hailey said, Arch does not come with the x32 ABI compiled, so I had to use -m32 and while we do get a 20% memory savings, we execute 50% slower because half the registers aren’t used! -m32 is the old 32-bit x86 mode using only 8 registers. To see the speed-up, we need to use -mx32 which uses the 64-bit instruction set with shrunken 32-bit pointers. But I don’t want to recompile Linux…
Unfortunately, Ubuntu also dropped x32 support.
\nLuckily, lazily, I have access to some deprecated servers (of course not in prod…) and OS installs, wasting hard disk space:
\n\n\nUbuntu 20.04 LTS Focal Fossa has reached its end of standard support on 31 May 2025.
\n
Ubuntu, so we have bash again:
\n\nCONFIG_X86_X32=y\nJust what we need, although gcc version 9.4.0 is a bit old. We already have build-essential git gcc-multilib libc6-dev-x32. We are ready to soar! Here is our full 32janet.sh:
#!/bin/bash\n\n\nTARGET="/janetx32"\nJANET="/bin/janet"\n\n\n# this forces Janet C libraries like Spork to build with 32bit also\n# FFI build test fails on -mx32 build so -DJANET_NO_FFI\n\n\n\n\n\n\n\n\n\n\n\n\n # speed gains\nPREFIX="" \nPREFIX="" \nPREFIX="" \nPREFIX="" \n\n\n\n\n\n# ### Packages\nPM="/lib/janet/bin/janet-pm"\n\n\n\nAnd a `64janet.sh to compare it with:
\n#!/bin/bash\n\n\nTARGET="/janet64"\nJANET="/bin/janet"\n\n\n\n\n\n\n\n # speed gains\nPREFIX="" \nPREFIX="" \nPREFIX="" \nPREFIX="" \n\n\n\n\n\n# ### Packages\nPM="/lib/janet/bin/janet-pm"\n\n\n\nNow we compare them:
\n\n\n\nBut declarative-dsls is a worst case scenario, using typed c arrays for big speed ups, which don’t benefit much from this. Lets make some minimal benchmarks to really test the differences:
\nSee the Benchmarks Scripts
\nwords.janet builds a text, splits it into words, counts them and sorts on that:
(let [start (os/clock :monotonic)\n rng (math/rng 42)\n vocab (seq [i :range [0 5000]] (string "w" (math/rng-int rng 100000)))\n text @""\n counts @{}]\n (repeat 600000 (buffer/push text (in vocab (math/rng-int rng 5000)) " "))\n (each word (string/split " " text)\n (put counts word (+ 1 (get counts word 0))))\n (pp (take 3 (sort-by |(- (in $ 1)) (pairs counts))))\n (print (length counts) " distinct words")\n (print (- (os/clock :monotonic) start) " s"))\nrecords.janet groups structs by department and summarizes those departments, with unused extra fields like real code:
(let [start (os/clock :monotonic)\n rng (math/rng 7)\n depts [:eng :ops :sales :legal :support]\n people (seq [i :range [0 300000]]\n {:id i\n # :name and :tags not used\n :name (string "person-" i)\n :dept (in depts (math/rng-int rng 5))\n :salary (+ 30000 (math/rng-int rng 90000))\n :tags [(math/rng-int rng 10) (math/rng-int rng 10)]})\n by-dept (group-by |(in $ :dept) people)]\n (each dept (sorted (keys by-dept))\n (let [staff (in by-dept dept)\n salaries (map |(in $ :salary) staff)]\n (pp [dept\n (length staff)\n (math/round (/ (sum salaries) (length staff)))\n (length (filter |(> $ 100000) salaries))])))\n (print (- (os/clock :monotonic) start) " s"))\nparse.janet parses lines with a PEG and totals them:
(let [start (os/clock :monotonic)\n rng (math/rng 3)\n lines (seq [i :range [0 200000]]\n (string i "," (math/rng-int rng 1000) ",item-" (math/rng-int rng 500) "," (/ (math/rng-int rng 10000) 100)))\n row (peg/compile\n ~{:num (number (some (set "0123456789.")))\n :txt (capture (some (if-not "," 1)))\n :main (* :num "," :num "," :txt "," :num -1)})\n rows (map |(peg/match row $) lines)\n totals @{}]\n (each [id qty item price] rows\n (put totals item (+ (get totals item 0) (* qty price))))\n (print (length rows) " rows, " (length totals) " items, total " (math/round (sum (values totals))))\n (print (- (os/clock :monotonic) start) " s"))\ntree.janet builds and walks binary trees, our pointer-heaviest example:
(let [start (os/clock :monotonic)\n make (fn make [depth]\n (if (= depth 0)\n [nil nil]\n [(make (- depth 1)) (make (- depth 1))]))\n check (fn check [node]\n (if (in node 0)\n (+ 1 (check (in node 0)) (check (in node 1)))\n 1))\n long-lived (make 19)]\n (var total 0)\n (repeat 40 (+= total (check (make 14))))\n (print total " " (check long-lived))\n (print (- (os/clock :monotonic) start) " s"))\nWe benchmark:
\nfor; do \n\n\n\n \n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n-mx32 cut RAM use by 21% (8-32%) with equal speed (-13% slower to 10% faster), while -x32 reduced speed by half. Janet is a worst case where nanboxing already packs values into 8 bytes so the main benefit’s smaller headers. I invite others to test their software and languages similarly. With continued x32 support, we could use this as a default for scripts, utilities, daemons and the like. I thus believe Linux distros should include -mx32 support and daemons and utilities should be compiled down for more efficient idling and day to day computing! It only costs a flag.
If Janet works with smaller object headers, why not shrink them in the implementation for 64-bit use? By my understanding, Janet heap objects use 16 bytes to help the garbage collector:
\nReducing these would require a different garbage collection strategy e.g. our own allocator, which would hurt a core Janet use case: embedding in other projects.
\nEach type then adds:
\nFor structs and tables in particular, we could regain 8 bytes through rearranging (not needing the later padding). Onlt tuples parsed from code need the source information (for errors); a flag could save normal tuples 8 bytes.
\nUnfortunately, glibc’s malloc adds 8 bytes and rounds to multiples of 16 so structs would remain the same. But tables and (some) tuples would shrunk more than the above indicates!
Kernels must be compiled with CONFIG_X86_X32_ABI providing syscall entry points on Linux (with no Windows and Mac equivalent) which the compilers expose via -mx32.
Good reading:
\nQuestions:
\nzig cc -target x86_64-linux-muslx32 crosscompile for easy distribution?