x32에서 실행한 Janet: 32비트 포인터, 64비트 속도, RAM 25% 절감

Linux x32 ABI는 64비트 명령어 집합을 유지하면서 32비트 포인터를 사용함. Janet 실험에서는 RAM 사용량이 평균 21% 줄었으며, 실행 속도는 작업에 따라 느려지거나 빨라짐 일반 32비트 빌드인 -m32와 x32 빌드인 -mx32는 다름. Arch에서 시험한 -m32는 메모리를 약 20% 절약했지만 실행 시간이 약 50% 늘어남 배포판 지원과 빌드 수정이 실용화의 제약임. 실험은 x32를 지원하는 Ubuntu 20.04에서 진행했으며, Janet의 값 레이아웃 판별을 수정하고 FFI를 비활성화해야 했음 네 가지 작업 모두 메모리 사용량이 줄었지만 속도 결과는 엇갈림. 레코드 집계와 PEG 파싱은 빨라졌고, 단어 집계와 트리 순회는 느려짐 Janet은 이미 NaN boxing으로 값을 8바이트에 담으므로, x32의 주된 이점은 객체 헤더 축소에서 나옴. 64비트 구현에서도 일부 헤더를 줄일 여지가 있지만, 가비지 컬렉션 방식과 메모리 할당기의 제약을 고려해야 함 32비트 포인터를 64비트 시스템에서 쓰는 이유 32비트 포인터를 쓰면 포인터 비중이 큰 힙에서는 메모리 사용량을 거의 절반까지 줄일 수 있으며, 캐시에 더 많은 데이터가 들어가 실행 속도도 소폭 높아질 수 있음 Linux x32 ABI가 이를 지원하지만 배포판 지원과 패키징은 제한적임 Debian에서는 기본적으로 비활성화되어 있으나 부팅 플래그로 켤 수 있음 Arch Linux는 커널에 해당 지원을 컴파일하지 않음 대부분의 소프트웨어는 x32로 컴파일할 수 있지만, 패키지가 부족해 거의 모든 것을 직접 빌드해야 함 Mastodon 배포 실험에서는 메모리 사용량이 650MB에서 350MB로 줄었음 보급을 확대하려면 조율과 소통 작업이 많이 필요하지만, 해당 실험자는 이를 직접 추진할 시간과 동기가 없다고 밝힘 Arch의 일반 32비트 빌드: 메모리 절약과 속도 저하 Spork 같은 Janet 라이브러리는 자체 빌드 플래그를 사용하므로, 기존 Janet 빌드 스크립트에 cc 래퍼를 추가해 실제 GCC를 -m32 -msse2 -mfpmath=sse로 실행하도록 함 래퍼 경로를 PATH 앞에 두고 JANET_TOOLCHAIN=cc를 지정해 라이브러리에도 같은 빌드 방식을 적용함 CachyOS 기반 Arch 환경에 lib32-glibc, lib32-gcc-libs를 설치하고 시험함 메모리 테스트는 [i (+ i 1)] 튜플을 배열에 계속 보관한...