Summary of "Running a Computer Without RAM"

High-level summary

Question: Can you replace system RAM (or run without it) by using disks, GPUs, or CPU cache? Short answer (from experiments): technically yes as a proof of concept, but practically no — performance and fundamental hardware/OS limitations make it unusable for general workloads.

Key technical concepts

• Swap / page file

  • The OS can write lesser-used memory pages to disk (or any nonvolatile storage). This is a contingency, not a replacement for RAM.
  • The CPU cannot execute directly from disk; pages must be swapped back into RAM before use.

• Turing-machine analogy

  • Permanent (tape/disk) memory exists in theory, but real systems need fast random access. Disk-like storage is too slow and has mechanical/addressing latency for general use.

• CPU caches

  • L1/L2/L3 caches on the CPU reduce latency versus DIMM RAM. In theory code could run inside cache, but caches are tiny (tens of MB at best).

• Swap-on-VRAM via FUSE/OpenCL

  • GPU VRAM can serve as a storage medium with high bandwidth, but OS access requires many software layers (loopback device → FUSE filesystem → userspace translator → OpenCL → GPU), adding large CPU overhead and latency.

• Why some workloads fail

  • Some operations (for example, game assets that must be present whole) require simultaneous access to multiple pages. Swap’s page-at-a-time behavior prevents atomic access to multi-page structures, causing crashes or unbootable apps.

Experiments performed

Common setup and tests

• System RAM was artificially reduced via a Linux boot parameter (tested 256, 384 MB; 512 MB was usable).
• One swap partition was disabled; a 4 GB swap was left on a SATA SSD.
• Tests used as stand-ins for real workloads:
  • Speedometer (browser benchmark) — Chromium incognito.
  • Raw memory-access benchmark (2 GB blocks, up to 512 GB total).
  • Portal 2 (2011) benchmark via Vulkan at max settings — stand-in for casual gaming.

1) Baseline and disk-swap tests — results

• Browser: usable but extremely slow (comparable to old low-end phones).
• Memory benchmark: far fewer completed operations versus control (control did 55 transfers; disk-swap managed 1).
• Portal 2: Steam UI crashed / failed to launch — not just a speed issue but an architectural limitation of swap (juggler analogy).

2) VRAM-as-swap (GPU memory) experiment

• Method:
  • Used VRAMmFS (FUSE filesystem backed by GPU memory via OpenCL) and created a loopback device to place a swap file on top of that FUSE FS.
• Hardware:
  • GTX 1660 Super (GDDR6, ~336 GB/s theoretical bandwidth) with only 6 GB VRAM.
  • Needed to increase system RAM to ~1 GB for VRAMmFS and OS to initialize.
• Results:
  • Browser benchmark took over an hour.
  • Memory benchmark froze the machine.
  • Portal 2 not attempted (expected failure).
• Explanation:
  • Raw GPU bandwidth is high, but the multiple indirections and user-space handling create huge overhead; overall much slower than direct RAM access and often unstable.

Other approaches discussed and dismissed

• Mounting network/cloud storage (e.g., Google Drive) as swap:

  • Terrible due to massive latency, and network stacks themselves need memory — impractical.

• Virtual machines / emulators:

  • Mainstream emulators don’t expose forcing all RAM to disk; host/emulator still need RAM, so it’s not an apples-to-apples comparison.

• Intel Optane:

  • A historical hybrid NV-RAM solution that tried to bridge RAM and SSD. Closest existing hardware approach, but discontinued and not a practical cheap replacement today.

Proof-of-concept: running without DIMM RAM using CPU cache

• Idea

  • Use Coreboot’s cache-as-RAM early stage to run code entirely from CPU cache before RAM is initialized.

• Implementation highlights and constraints

  • Modified Coreboot to run a small payload during the cache-as-RAM stage.
  • Wrote minimal programs: a Brainfuck interpreter and a tiny Snake game fit; an NES emulator ROM was too large for cache.
  • I/O via serial port (no video drivers at that early stage); used a serial terminal with text and ANSI colors to emulate a low-res display.
  • Required hardware:
    • Old/unlocked motherboard or ability to flash/remove BIOS chip (modern UEFI protections prevented this on many boards).
    • Example hardware: attempted Dell Latitude D630 (bricked or needed external flasher) and ASRock G31M/G41M-era desktop board with detachable BIOS chip.
  • Flashed Coreboot using a microcontroller / breadboard to program a removable BIOS chip, removed RAM sticks and peripherals.
  • Demo: Snake running on CPU with no RAM installed, output to host laptop via serial-over-USB. Very slow; removing the BIOS flash while running froze the board because that CPU read ROM constantly (did not cache ROM).

Practical conclusions and takeaways

• Replacing RAM with disk (SSD/SATA) is technically possible via swap but introduces order-of-magnitude slowdowns; some simple tasks are possible, many apps (games, complex UIs) will fail.
• Using VRAM as swap is theoretically promising for bandwidth, but software indirection and user-space layers make it worse than expected and often unstable.
• Running purely from CPU cache is possible for tiny programs by taking over early boot (Coreboot, cache-as-RAM), but it is extremely limited, hardware-specific, fragile, and unsuitable for general computing.
• For practical/cost-saving needs, the realistic options remain: buy compatible DRAM, wait for price normalization, or investigate hybrid/legacy solutions (e.g., Optane historically). There is no free or viable drop-in substitute for system RAM today.

Relevant tools, projects, benchmarks, and hardware (for replication)

• Linux boot kernel parameter to limit available RAM.
• Speedometer (browser benchmark) — Chromium incognito.
• Custom memory benchmark (2 GB blocks up to 512 GB).
• Portal 2 (Vulkan), Steam (Chromium-based UI).
• VRAMmFS (GitHub project by Alexander Overboard) — FUSE-based GPU-backed filesystem via OpenCL.
• Loopback device + swap file layered on top of FUSE.
• Coreboot — used to boot into cache-as-RAM stage and run custom payloads.
• Hardware examples:
  • GTX 1660 Super (GDDR6)
  • Ryzen 5 3600 (cache sizes)
  • ASRock G31M/G41M boards
  • Dell Latitude D630 (old laptop)
  • Litech RV Nano (tiny device reference)
• Intel Optane (historical mention).

Guides / how-to (summary)

To reproduce limited-RAM tests:

1. Limit system RAM via a Linux boot parameter.
2. Disable extra swap partitions; configure a small swap file on a chosen device (SATA SSD used here).
3. Run Speedometer in Chromium incognito, run the memory benchmark, and attempt Portal 2 to test real-world behavior.

To try VRAM swap:

1. Install VRAMmFS (Alexander Overboard’s project) and ensure OpenCL drivers are available.
2. Create and mount the FUSE-backed filesystem on the GPU.
3. Create a loopback device pointing to a file on that FUSE FS.
4. Put a swap file on the loopback device, enable it, then disable other swap to force VRAM swap usage.
5. Note: VRAMmFS and FUSE allocation require some host RAM; expect instability and high overhead.

To run code inside CPU cache (very advanced / risky):

1. Use old hardware with unlocked BIOS flash and a serial port.
2. Build and flash Coreboot (or modify an existing Coreboot stage) to run a custom payload during cache-as-RAM initialization.
3. Keep the payload tiny (must fit in CPU cache); use serial for I/O.
4. Be prepared to brick boards if flashing fails.

Sponsors / other mentions

• TryHackMe (cybersecurity learning platform) — sponsor mentioned with promo code (runner30). Features: hands-on VMs and roadmaps from beginner to certification.

Main speakers / primary sources referenced

• The experimenter / video narrator (first-person, performed the experiments and modified Coreboot).
• Alexander Overboard — author of VRAMmFS.
• Coreboot project — used as the open-source firmware base.
• TryHackMe — sponsor/platform mentioned.

Overall impression

The exploration is a hands-on technical demonstration showing that while you can force systems to operate with very little or no DIMM RAM by using swap, GPU memory, or CPU cache, each approach has severe practical limitations. The experiments illustrate the architectural bottlenecks (latency, indirection, OS/hardware assumptions) and present an extreme proof-of-concept (running a tiny game in CPU cache via Coreboot), not a practical replacement for system RAM.

Category

Technology

---

Share this summary

Share on X/Twitter Share on Facebook Share on LinkedIn Share on Reddit Share on WhatsApp Share on Telegram

---

Is the summary off?

If you think the summary is inaccurate, you can reprocess it with the latest model.

Reprocess summary

Video