It’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
\nJanet 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\nset -eu\nTARGET="$PWD/janet32"\nJANET="$TARGET/bin/janet"\nmkdir -p "$TARGET/cc32"\nprintf '#!/bin/sh\\nexec gcc -m32 -msse2 -mfpmath=sse "$@"\\n' > "$TARGET/cc32/cc"\nchmod +x "$TARGET/cc32/cc"\nexport PATH="$TARGET/cc32:$PATH"\nexport JANET_TOOLCHAIN=cc\nunset JANET_PATH JANET_TREE\nmkdir -p "$TARGET"\ncd "$TARGET"\nrm -rf build/spork janet\ngit clone https://github.com/janet-lang/janet\ncd janetEasy enough! Now let’s try it!
\ntl;dr: 20% memory reduction, 50% slower
\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)))Note, these use Fish and I don’t want to rebuild my site with other language support:
\nsudo pacman -S time # different from just time\ncommand time -v ./bin/janet mem.janet # command skips the fish version\ncommand time -v ./janet32/bin/janet mem.janet\n2000000\n Command being timed: "./bin/janet mem.janet"\n User time (seconds): 0.24\n System time (seconds): 0.05\n Percent of CPU this job got: 100%\n Elapsed (wall clock) time (h:mm:ss or m:ss): 0:00.30\n Average shared text size (kbytes): 0\n Average unshared data size (kbytes): 0\n Average stack size (kbytes): 0\n Average total size (kbytes): 0\n Maximum resident set size (kbytes): 145196\n Average resident set size (kbytes): 0\n Major (requiring I/O) page faults: 0\n Minor (reclaiming a frame) page faults: 33513\n Voluntary context switches: 1\n Involuntary context switches: 9\n2000000\n Command being timed: "./janet32/bin/janet mem.janet"\n User time (seconds): 0.47\n System time (seconds): 0.03\n Percent of CPU this job got: 99%\n Elapsed (wall clock) time (h:mm:ss or m:ss): 0:00.50\n Average shared text size (kbytes): 0\n Average unshared data size (kbytes): 0\n Average stack size (kbytes): 0\n Average total size (kbytes): 0\n Maximum resident set size (kbytes): 113716\n Average resident set size (kbytes): 0\n Major (requiring I/O) page faults: 0\n Minor (reclaiming a frame) page faults: 25686\n Voluntary context switches: 1\n Involuntary context switches: 21I added a 0 in the test
\ncommand time -v ./bin/janet mem.janet\n command time -v ./janet32/bin/janet mem.janet\n20000000\n Command being timed: "./bin/janet mem.janet"\n User time (seconds): 2.83\n System time (seconds): 0.46\n Percent of CPU this job got: 99%\n Elapsed (wall clock) time (h:mm:ss or m:ss): 0:03.31\n Average shared text size (kbytes): 0\n Average unshared data size (kbytes): 0\n Average stack size (kbytes): 0\n Average total size (kbytes): 0\n Maximum resident set size (kbytes): 1410668\n Average resident set size (kbytes): 0\n Major (requiring I/O) page faults: 0\n Minor (reclaiming a frame) page faults: 316820\n Voluntary context switches: 1\n Involuntary context switches: 164\n Exit status: 0\n20000000\n Command being timed: "./janet32/bin/janet mem.janet"\n User time (seconds): 4.64\n System time (seconds): 0.35\n Percent of CPU this job got: 99%\n Elapsed (wall clock) time (h:mm:ss or m:ss): 0:05.00\n Average shared text size (kbytes): 0\n Average unshared data size (kbytes): 0\n Average stack size (kbytes): 0\n Average total size (kbytes): 0\n Maximum resident set size (kbytes): 1098372\n Average resident set size (kbytes): 0\n Major (requiring I/O) page faults: 0\n Minor (reclaiming a frame) page faults: 238633\n Voluntary context switches: 1\n Involuntary context switches: 193For e.g. declarative-dsls/tests.janet
98 passed\n Command being timed: "./bin/janet ./lib/janet/bin/judge declarative-dsls/tests.janet"\n User time (seconds): 0.42\n System time (seconds): 0.02\n Percent of CPU this job got: 100%\n Elapsed (wall clock) time (h:mm:ss or m:ss): 0:00.45\n Average shared text size (kbytes): 0\n Average unshared data size (kbytes): 0\n Average stack size (kbytes): 0\n Average total size (kbytes): 0\n Maximum resident set size (kbytes): 61900\ndeclarative-dsls/tests.janet\n98 passed\n Command being timed: "./bin/janet ./lib/janet/bin/judge declarative-dsls/tests.janet"\n User time (seconds): 0.70\n System time (seconds): 0.02\n Percent of CPU this job got: 99%\n Elapsed (wall clock) time (h:mm:ss or m:ss): 0:00.72\n Average shared text size (kbytes): 0\n Average unshared data size (kbytes): 0\n Average stack size (kbytes): 0\n Average total size (kbytes): 0\n Maximum resident set size (kbytes): 54108\n Average resident set size (kbytes): 0\n Major (requiring I/O) page faults: 0\n Minor (reclaiming a frame) page faults: 12735As 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:
\nUbuntu 20.04 LTS Focal Fossa has reached its end of standard support on 31 May 2025.
\nUbuntu, so we have bash again:
\ngrep X86_X32 /boot/config-$(uname -r) \nCONFIG_X86_X32=yJust 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’re almost ready to test this hunch. But first, we must change src/include/janet.h:
#if ((defined(__x86_64__) || defined(_M_X64)) \\\n && (defined(JANET_POSIX) || defined(JANET_WINDOWS))) \\becomes:
\n#if ((defined(__x86_64__) || defined(_M_X64)) && !defined(__ILP32__) \\\n && (defined(JANET_POSIX) || defined(JANET_WINDOWS))) \\lest Janet choose the 64-bit value layout. Our build script will also pass a build flag to disable Janet’s FFI. Here is our full 32janet.sh:
#!/bin/bash\nset -eu\nTARGET="$PWD/janetx32"\nJANET="$TARGET/bin/janet"\nmkdir -p "$TARGET/cc32"\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\nprintf '#!/bin/sh\\nexec gcc -mx32 -DJANET_NO_FFI "$@"\\n' > "$TARGET/cc32/cc"\nchmod +x "$TARGET/cc32/cc"\nexport PATH="$TARGET/cc32:$PATH"\nexport JANET_TOOLCHAIN=cc\nunset JANET_PATH JANET_TREE\nmkdir -p "$TARGET"\ncd "$TARGET"\ngit clone https://github.com/janet-lang/janet\ncd janet\n# make the change to Janet source\ngit checkout -q 0e5fdd53 # otherwise this sed will bit rot\nsed -i 's/^#if ((defined(__x86_64__) || defined(_M_X64)) \\\\$/#if ((defined(__x86_64__) || defined(_M_X64)) \\&\\& !defined(__ILP32__) \\\\/' src/include/janet.h\nexport CFLAGS='-fPIC -O3 -flto -fno-semantic-interposition -march=native' # speed gains\nPREFIX="$TARGET" make clean\nPREFIX="$TARGET" make\nPREFIX="$TARGET" make test\nPREFIX="$TARGET" make install\ncd ..\ngit clone --depth=1 https://github.com/janet-lang/spork build/spork\n"$JANET" -e '(if (bundle/installed? "spork") (bundle/replace "spork" "build/spork") (bundle/install "build/spork"))'\n# ### Packages\nPM="$TARGET/lib/janet/bin/janet-pm"\ngit clone https://codeberg.org/veqq/declarative-dsls\n"$JANET" "$PM" install file::declarative-dsls # also does https://codeberg.org/veqq/varray\ngit clone https://github.com/ianthehenry/judge # also does https://github.com/ianthehenry/cmd\n"$JANET" "$PM" install file::judge\ntime "$JANET" "$TARGET/lib/janet/bin/judge" declarative-dsls/tests.janet # to show that it workedAnd a `64janet.sh to compare it with:
\n#!/bin/bash\nset -eu\nTARGET="$PWD/janet64"\nJANET="$TARGET/bin/janet"\nunset JANET_PATH JANET_TREE\nmkdir -p "$TARGET"\ncd "$TARGET"\ngit clone https://github.com/janet-lang/janet\ncd janet\ngit checkout -q 0e5fdd53 # same commit as the x32 build\nexport CFLAGS='-fPIC -O3 -flto -fno-semantic-interposition -march=native' # speed gains\nPREFIX="$TARGET" make clean\nPREFIX="$TARGET" make\nPREFIX="$TARGET" make test\nPREFIX="$TARGET" make install\ncd ..\ngit clone --depth=1 https://github.com/janet-lang/spork build/spork\n"$JANET" -e '(if (bundle/installed? "spork") (bundle/replace "spork" "build/spork") (bundle/install "build/spork"))'\n# ### Packages\nPM="$TARGET/lib/janet/bin/janet-pm"\ngit clone https://codeberg.org/veqq/declarative-dsls\n"$JANET" "$PM" install file::declarative-dsls # also does https://codeberg.org/veqq/varray\ngit clone https://github.com/ianthehenry/judge # also does https://github.com/ianthehenry/cmd\n"$JANET" "$PM" install file::judge\ntime "$JANET" "$TARGET/lib/janet/bin/judge" declarative-dsls/tests.janet # to show that it workedNow we compare them:
\nsudo apt install time # different from just time\n/usr/bin/time -f '%e s %M KB' janet64/bin/janet janet64/lib/janet/bin/judge janet64/declarative-dsls/tests.janet\n/usr/bin/time -f '%e s %M KB' janetx32/bin/janet janetx32/lib/janet/bin/judge janetx32/declarative-dsls/tests.janet\n2.42 s 61668 KB # 64bit\n2.36 s 53472 KB # 32bitBut 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:
\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"))records.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"))parse.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"))tree.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"))We benchmark:
\nfor f in words records tree parse; do \n> /usr/bin/time -f "$f 64: %e s %M KB" janet64/bin/janet $f.janet > /dev/null \n> /usr/bin/time -f "$f x32: %e s %M KB" janetx32/bin/janet $f.janet > /dev/null \n> done \n> \nwords 64: 0.58 s 41904 KB \nwords x32: 0.67 s 31856 KB \nrecords 64: 6.40 s 138164 KB \nrecords x32: 5.80 s 126916 KB \ntree 64: 1.39 s 50504 KB \ntree x32: 1.50 s 35532 KB \nparse 64: 3.20 s 58504 KB \nparse x32: 3.19 s 44428 KB\nwords 64: 0.63 s 41984 KB \nwords x32: 0.70 s 31976 KB \nrecords 64: 6.71 s 138240 KB \nrecords x32: 5.77 s 126844 KB \ntree 64: 1.40 s 50392 KB \ntree x32: 1.48 s 35304 KB \nparse 64: 3.37 s 58592 KB \nparse x32: 3.09 s 44496 KB\nwords 64: 0.59 s 41756 KB \nwords x32: 0.67 s 31788 KB \nrecords 64: 6.50 s 138384 KB \nrecords x32: 5.80 s 126960 KB \ntree 64: 1.39 s 50288 KB \ntree x32: 1.43 s 35560 KB \nparse 64: 3.35 s 58520 KB \nparse x32: 3.24 s 44572 KB\nwords 64: 0.60 s 42012 KB \nwords x32: 0.67 s 31896 KB \nrecords 64: 6.29 s 138448 KB \nrecords x32: 6.00 s 126832 KB \ntree 64: 1.38 s 50176 KB \ntree x32: 1.43 s 35392 KB \nparse 64: 3.36 s 58384 KB \nparse x32: 3.13 s 44364 KBWe see the highest memory savings from tiny objects, averaging about 25% with inconsistent speed ups (8%) or slowdowns (16%). Perhaps other projects are more ammenable to gains than Janet where nanboxing already packs values into 8 bytes and smaller headers see the main benefit. Midway through, I was hoping for performance gains due to more staying in the L1 cache etc. where, in another world with continued x32 support, we could use this as a default for scripts. Faced with the data, the only ~25% decrease in RAM usage is nice, but does not justify a call to action to get more out of our machines in this age of expensive RAM.
\nIf 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!