The answer is more nuanced than you might think. While traditional computing absolutely requires some form of fast memory, the boundaries of what's possible are surprisingly flexible. Let's explore the technical realities, practical experiments, and theoretical foundations of computing with minimal or zero RAM.
Before we get into the exotic solutions, let's address the elephant in the room. Every modern operating system has a mechanism for dealing with memory shortages. Windows calls it a pagefile, Linux calls it swap, but the concept remains consistent across platforms.
When your system runs low on physical memory, the operating system implements a contingency plan. It identifies the least recently used pages of memory and writes them to disk, freeing up RAM for more urgent tasks. This process, known as paging or swapping, effectively extends your available memory by using disk space as overflow storage.
The technique dates back to the 1960s, making it one of the oldest tricks in the computing playbook. Atlas, one of the pioneering computer systems at the University of Manchester, introduced virtual memory with paging in 1962. The fundamental problem it solves remains unchanged: memory is expensive and limited, while storage is cheap and plentiful.
However, swap space doesn't actually eliminate the need for RAM. The processor cannot execute instructions directly from disk. Every operation must first be loaded into physical memory, processed, and then potentially swapped back out. The RAM acts as a mandatory staging area for all computation.
To understand the practical implications of memory constraints, let's examine what happens when we reduce available RAM to near nothing. Starting with a modern Linux system, we can use boot parameters to artificially limit available memory.
The initial target was 256 megabytes. Surprisingly, this proved insufficient. The system froze while attempting to allocate the initial ramdisk during boot. This failure is instructive because smaller embedded devices like the LicheeRV Nano operate successfully with exactly this amount, though half is reserved for camera and display drivers. Desktop systems, with their complex initialization sequences and numerous drivers, simply require more overhead.
After multiple attempts and one temporarily unbootable system requiring external intervention, 512 megabytes emerged as the minimum viable configuration. Combined with 4 gigabytes of swap on a SATA SSD, this setup created an environment where nearly all active working memory resided on disk rather than in physical RAM.
The performance implications were severe but predictable. A browser benchmark that simulates typical web usage took dramatically longer to complete. The raw memory access test managed only one transfer operation compared to 55 in the control configuration. Most tellingly, attempting to launch Portal 2 through Steam simply crashed the application before the game could even initialize.
This crash reveals a fundamental limitation of swap-based approaches. Think of swap like a juggler who can only hold one ball at a time while the rest remain in the air. For simple sequential operations, this works adequately. But when a game texture or 3D model requires two balls worth of memory simultaneously, the juggler cannot hold both pieces at once. The processor needs the complete asset loaded into physical memory to operate on it as a whole unit.
Even with faster NVMe storage, this approach hits a performance wall. The latency of disk access, measured in milliseconds, simply cannot compete with RAM access times measured in nanoseconds. That's a difference of six orders of magnitude.
Graphics cards contain their own dedicated memory pools, separate from system RAM. Modern GPUs feature high-bandwidth GDDR6 or even GDDR6X memory, with theoretical bandwidths exceeding 300 gigabytes per second. This vastly outpaces even the fastest consumer SSDs. Could we repurpose this video memory for general computation?
The OpenCL API provides raw byte-level access to GPU memory, enabling arbitrary read and write operations. A project called vramfs leverages this capability to create a FUSE filesystem backed by video memory. In essence, it translates standard filesystem operations into GPU memory accesses, allowing swap files to reside in VRAM rather than on disk.
The setup process revealed immediate challenges. With system RAM limited to 512 megabytes and 4 gigabytes allocated from a 6GB graphics card, the desktop environment crashed during initialization. The filesystem emulation itself requires substantial memory allocation, creating a chicken-and-egg problem. The system attempts to free memory by killing processes but cannot determine which are critical until it's too late.