I help teams fix systemic engineering issues: processes, architecture, and clarity.
→ See how I work with teams.
This article revisits HPE's The Machine project and the original promise of memristor based universal memory. It explains the idea of memory driven computing, where large pools of persistent memory replace the classic hierarchy of caches, DRAM and external storage. It then analyzes what this means for data platforms, AI workloads and distributed systems design, and how architects can still apply the underlying concepts today using modern non volatile memory, memory fabrics and high density shared memory systems.
HPE The Machine, Memristors and the Future of Memory Driven Computing
Back in 2014 to 2017 HPE promoted The Machine as a radical rethinking of computer architecture. Instead of building systems around processors and attaching memory and storage, the design started from a very large shared memory pool and placed compute nodes around it. The original plan talked about memristor based non volatile memory, photonic interconnects and a new operating system layer tuned for this model.
The public prototypes that appeared around 2016 and 2017 were already more conservative than the earliest vision. They used large amounts of DRAM instead of commercial memristor modules, but they kept the central idea of fabric attached memory and photonic interconnects. A 40 node prototype with about 160 TB of shared memory and 1,280 cores demonstrated what a memory driven system could look like in practice.
From CPU Centric to Memory Driven Architectures
Classic computer designs revolve around CPUs and their local DRAM. Storage is a separate layer, usually reachable through block protocols, filesystems or object stores. Cache hierarchies hide the latency differences. Data platforms and distributed systems are built around this reality. We cache aggressively, shuffle data across networks and move work to where data is stored or vice versa.
Memory driven computing turns that picture around. The main resource of the system is a large pool of byte addressable memory that can be reached with near uniform latency from many compute nodes. Persistent memory technology bridges the gap between DRAM and storage. Photonic or other high bandwidth interconnects tie everything together. The consequence is that the line between memory and storage becomes blurred and, for many workloads, disappears.
The Memristor Vision
The original version of The Machine was closely tied to the memristor concept. A memristor is an element whose resistance depends on the history of current that passed through it. In practical memory designs this can be used to build non volatile memory cells. The idea was to create modules with DRAM like latency, non volatility and very high density. In theory this would allow a single architecture to cover roles that we currently map to DRAM, flash and parts of disk based storage.
For the article that you wrote in 2017, that vision was still directly attached to The Machine roadmap. It was reasonable to expect that memristor based non volatile memory would show up in early systems around 2018 to 2020. In reality the hardware side turned out to be much harder. Prototypes switched to DRAM and other non volatile technologies have taken the lead in the market. The memristor idea did not vanish, but it moved into research areas and niche technologies rather than mainstream server products.
What The Machine Actually Demonstrated
Even without memristor modules the prototypes were interesting from an architectural perspective. They showed what happens if you treat memory capacity and bandwidth as the primary design constraint and organize compute around it. A few important aspects stand out:
- Fabric attached memory that is reachable from many nodes rather than local DRAM per socket only.
- A clear separation between local cache coherent memory and a much larger pool of shared memory.
- Photonic or high speed fabric links that blur the line between local and remote access for many workloads.
- A software stack that has to treat memory as a networked, partially non uniform resource.
This is not only a hardware story. It affects how data structures are built, how runtimes manage state and how algorithms traverse memory. An in memory database or analytics engine behaves differently when it can assume that hundreds of terabytes of memory are directly addressable compared to a setup where data is sharded across many independent machines.
Implications for Data Processing and AI Workloads
In your original text you already connected The Machine to pattern detection and Monte Carlo methods. That intuition is still valid. Many AI and simulation workloads have the same recurring pattern. They operate on large state spaces, reuse partial results and traverse large graphs or parameter sets. The more of this state fits into directly addressable memory, the less time is spent on I O and shuffling.
Consider large Markov Chain Monte Carlo runs, graph algorithms or tree based models that explore wide search spaces. In a classic setup we constantly serialize and deserialize state between memory and storage, or between processes in a cluster. In a memory driven setup there is a much larger shared space where partial results can remain resident. Subsequent runs or related models can attach to that space instead of reconstructing it.
For deep learning and modern machine learning systems, very large model weights and feature stores are another obvious use case. While GPU memory dominates training, system level memory capacity and bandwidth shape data loading, feature lookup and pre processing pipelines. Infer
If you need help with distributed systems, backend engineering, or data platforms, check my Services.