--- title: The Prospects for 128 Bit Processors ( John Mashey SGI 1995) description: A 1995 Usenet post by John R. Mashey of Silicon Graphics analyzes when 128-bit processors might become necessary. Using DRAM density growth rates (4x every 3... canonical: https://daily.dev/posts/the-prospects-for-128-bit-processors-john-mashey-sgi-1995--lcqtgxlwl twitter:card: summary_large_image twitter:site: @dailydotdev og:type: website og:site_name: daily.dev og:title: The Prospects for 128 Bit Processors ( John Mashey SGI 1995) | daily.dev og:description: A 1995 Usenet post by John R. Mashey of Silicon Graphics analyzes when 128-bit processors might become necessary. Using DRAM density growth rates (4x every 3... og:url: https://daily.dev/posts/the-prospects-for-128-bit-processors-john-mashey-sgi-1995--lcqtgxlwl og:image: https://api.daily.dev/og/posts/lcqtgxlWL.png og:image:alt: The Prospects for 128 Bit Processors ( John Mashey SGI 1995) og:image:width: 1200 og:image:height: 630 og:locale: en --- > ## Documentation Index > Fetch the complete documentation index at: https://daily.dev/llms.txt > Use this file to discover all available pages before exploring further. # The Prospects for 128 Bit Processors ( John Mashey SGI 1995) **[Hacker News](https://daily.dev/sources/hn)** · 8 min read · 1 upvotes · 1 comments ## Summary A 1995 Usenet post by John R. Mashey of Silicon Graphics analyzes when 128-bit processors might become necessary. Using DRAM density growth rates (4x every 3 years, or 2 bits per 3 years) as the primary driver, he calculates that physical memory pressure alone would push the 64-to-128-bit transition to around 2043. Virtual memory pressure from memory-mapped files and sparse files could accelerate this to around 2020. He also dismisses 1024-bit processors as impractical for at least 30 years due to physical chip constraints. The key insight is that the 64-to-128-bit transition will take roughly twice as long as the 32-to-64-bit transition, contrary to common assumptions. ## Full article daily.dev links to this article rather than hosting it. Read it at the original source: ## Community take How the wider developer community reacted, aggregated from 3 discussions and 306 comments across hackernews (as of 2026-08-02). **TL;DR:** The community finds the 1995 analysis impressively prescient and technically grounded, with lively discussion about why 128-bit addressing remains unnecessary (speed-of-light memory latency, clusters replacing shared memory, current CPUs only using 48-52 bits), while noting that 128-bit registers already exist in SIMD/vector units and the more interesting near-term use cases are 128-bit atomics, fat pointers, and quad-precision floats. **Sentiment:** 55% positive · 35% mixed · 10% skeptical **The case for** - Several commenters note the analysis aged well: the 64-bit address space is still far from exhausted, validating Mashey's long timeline. - 128-bit atomic operations (CMPXCHG16B) are already useful for lock-free programming with two-pointer structures. - CHERI capabilities and fat pointers represent a practical near-term use for 128-bit-wide pointer-like values without requiring a full 128-bit address space. - IBM AS/400 and S/38 are cited as real historical examples of 128-bit object addressing, showing the idea has practical precedent. - RISC-V already reserves space for a 128-bit ISA variant, showing forward-thinking design. **The pushback** - The speed of light physically limits how far memory can be from a CPU, making a single shared 128-bit address space impractical for performance reasons. - Modern systems scaled via more CPUs with separate address spaces rather than larger shared memory, undermining the core assumption. - Current x86-64 and ARM CPUs only use 48-52 bits of address space, meaning 64-bit addressing headroom is far from exhausted. - Doubling register width doubles pointer size, cutting effective cache capacity in half and hurting performance. - 128-bit floating point is rarely needed because precision loss is often exponential, making even 128 bits insufficient for many ill-conditioned problems. **By community** - hackernews (mixed): Commenters are broadly impressed by the analysis and enjoy the historical context, but debate whether 128-bit addressing will ever be needed given physical memory limits, cluster computing trends, and the fact that SIMD units already provide wide registers for most practical needs. **Hottest debate:** Whether 128-bit general-purpose addressing will ever be necessary, given that clusters of machines with separate address spaces have replaced monolithic shared-memory scaling, and the speed of light constrains how much memory a single CPU can usefully address. **Open questions** - Will LLM KV-cache memory demands or persistent-memory (Optane-style) architectures eventually push systems toward exhausting 64-bit address spaces? - Could CHERI-style capability hardware or fat pointers become mainstream without requiring a full 128-bit ISA transition? - When (if ever) will hardware quad-precision (128-bit) floating point become standard given its niche but real scientific use? - How would a global, routable, byte-level address space actually be coordinated to avoid fragmentation? **Highlights** > From Jeff Bonwick, ZFS Developer: Although we'd all like Moore's Law to continue forever, quantum mechanics imposes some fundamental limits on the computation rate and information capacity of any physical device. In particular, it has been shown that 1 kilogram of matter confined to 1 liter of space can perform at most 10^51 operations per second on at most 1031 bits of information [see Seth Lloyd, "Ultimate physical limits to computation." Nature 406, 1047-1054 (2000)]. A fully-populated 128-bit storage pool would contain 2^128 blocks = 2^137 bytes = 2140 bits; therefore the minimum mass required to hold the bits would be (2^140 bits) / (10^31 bits/kg) = 136 billion kg. That's a lot of gear. To operate at the 10^31 bits/kg limit, however, the entire mass of the computer must be in the form of pure energy. By E=mc^2, the rest energy of 136 billion kg is 1.2x10^28 J. The mass of the oceans is about 1.4x10^21 kg. It takes about 4,000 J to raise the temperature of 1 kg of water by 1 degree Celcius, and thus about 400,000 J to heat 1 kg of water from freezing to boiling. The latent heat of vaporization adds another 2 million J/kg. Thus the energy required to boil the oceans is about 2.4x10^6 J/kg * 1.4x10^21 kg = 3.4x1^027 J. Thus, fully populating a 128-bit storage pool would, literally, require more energy than boiling the oceans. > — [vimax on hackernews](https://news.ycombinator.com/item?id=30450432) > We already have 128-bit computers if you're willing to count 128-bit vector units. (The internal data path of most CPUs is 128-bit these days). So the basic problem with 128-bit comes down to one thing: memory. There is a physical limitation on the amount of memory you can have ready to access; if you've paid attention, there has been basically no growth in the size of caches in the past decade. Doubling the memory size of your basic constituents means you cut the effective size of that cache in half, and effectively using that cache is the biggest barrier to performance. If you look at prior sizes, it's clear that 16-bits is way too small-that's 65,536 entries, which is easy to overflow in many cases. 32-bits gives you about 4 billion entries, which is generally sufficient for the vast majority of cases, but can overflow (it only takes ~1 second for a CPU to count to 4 billion). Overflowing 64-bits in a counter would take that same CPU a century to do, and it should be rapidly clear that there's not much that's going to use it. Consider your use case of address spaces. Memory can't get all that much smaller; we're starting to come up on laws of physics, so there's only a factor of 1,000× or so smaller that we can get. We're barely at the threshold right now of exhausting the existing 48-bit address spaces (or 256TiB of memory), and even then, that requires things like memory-mapping entire disk drives to eat up that much memory. Apply that factor of 1,000 shrinkage, and you still don't cross the 16EiB threshold of a 64-bit address space. The need to address that much memory just isn't in the cards, and if it is, the memory is likely to be so heavily non-uniform that you'd probably see a development towards segmented address spaces again anyways to avoid needing 128-bit pointers generally. The one use case that I consider the most likely is adding hardware support for quad-precision floating point numbers, since it already exists in several libraries as a soft float operation, it's well-understood, the datapaths can generally already handle it (a 128-bit vector FMA unit can relatively easily be extended to support a 128-bit scalar floating-point FMA anyways), and there's a small need for it. > — [jcranmer on hackernews](https://news.ycombinator.com/item?id=30450342) > So reflecting on that, I think the core assumption that didn't pan out is that the memory / CPU ratio will grow because we'll need more memory, hence requiring CPUs to address more than 16 EiB of data (16 EiB = 16384 PiB = 16777216 TiB of data, what 64 bits can address). But in practice, we've produced a lot more compute. The memory / CPU ratio has increased, but most growth has been from more CPUs (and generally not shared-memory ones, but ones with their own completely separate memory space). IPv6 is 128 bit, so we do have 128 bit ways of addressing computers, but I'd say we're still a long way from a CPU needing to address that much memory as a common case. The speed of light limits how far away memory can be from the CPU for good performance, so short of some drastically new memory technology, it seems unlikely we'll need it soon for any ordinary type of computing device. > — [A1kmm on hackernews · 2 comments](https://news.ycombinator.com/item?id=49141422) > We already have 128-bit processors, of sorts. They are called "vector units". ;) 128-bit integers could be useful for bignums. You can do bignum addition on existing SIMD units but you'd have to use tricks to carry the carry between elements and to the next vector — and that makes the resulting code slower than using GPRs.[1] But I think this would still fit better in vector units than making the integer registers larger: The hw trend (ARM SVE, RISC-V V) is to make vector-width implementation-defined, starting at 128 bits in the low-end. 128-bit floating point is apparently a thing in scientific computing (but I've not seen it myself). 128-bit "pointers" exist in CHERI [2], where they are tagged capabilities that also store the bounds and access rights (rwx) for accessing memory through the pointer. Addresses are still 64-bit though. GPRs are still 64-bit. The caps are stored in a new register file. If you want to scale up address spaces, I think the biggest issue is not the number of bits but rather how to coordinate the address space to avoid collisions. One approach would be to re-introduce segmentation (pointer ⇒ segment ID and offset within segment), but unlike earlier system make each segment have its own local namespace of segment IDs it knows and translate between those when transferring pointers between segments. This idea is used by e.g. the research OS "Twizzer" [3], which was made for a large address space using NVRAM as RAM. I think this "pointer swizzling" could also be helped by hardware support. [1] Integer Addition and Carryout, by Alexander Yee [2] Capability Hardware Enhanced RISC Instructions (CHERI) [3] Twizzler: An Operating System for Next-Generation Memory Hierarchies > — [Findecanor on hackernews · 2 comments](https://news.ycombinator.com/item?id=30448063) > It is not too difficult to imagine for virtual memory. Servers with high storage density are right up against the current virtual memory limits such that you can't mmap() storage as it is. Not that you'd want to mmap() if you cared about performance. Similarly, the largest data models have been in the exabyte range for a while. It is just a matter of time before they are not byte-addressable using a 64-bit integer. I think there is more utility in 128-bit ALUs than 128-bit pointers, as a practical matter. > — [jandrewrogers on hackernews · 2 comments](https://news.ycombinator.com/item?id=30447214) **Source threads** - [hackernews](https://news.ycombinator.com/item?id=49140174) · 25 points · 20 comments - [hackernews](https://news.ycombinator.com/item?id=30446415) · 85 points · 198 comments - [hackernews](https://news.ycombinator.com/item?id=40405426) · 32 points · 88 comments ## Community discussion Top comments from developers on daily.dev. **@pkraszewski** · 0 upvotes > And we already have [RV128I](https://docs.riscv.org/reference/isa/v20240411/unpriv/rv128.html). Unfortunately, supported only via experimental GCC and no OS. ## Similar posts on daily.dev - [16GB of RAM is still perfectly usable in 2026, and I'm tired of pretending it isn't](https://daily.dev/posts/16gb-of-ram-is-still-perfectly-usable-in-2026-and-i-m-tired-of-pretending-it-isn-t-euhs1jdqy) · XDA Developers · 0 upvotes · 0 comments - [Intel is reportedly launching new CPUs on a five-year-old socket to allow DDR4](https://daily.dev/posts/intel-is-reportedly-launching-new-cpus-on-a-five-year-old-socket-to-allow-ddr4-qmjwytdub) · The Next Web · 0 upvotes · 0 comments - [The Alpha 21264: NT's Greatest RISC](https://daily.dev/posts/the-alpha-21264-nt-s-greatest-risc-ijnnoyaxa) · Hacker News · 0 upvotes · 0 comments --- Tags: [#hardware](https://daily.dev/tags/hardware) [View this post on daily.dev](https://daily.dev/posts/the-prospects-for-128-bit-processors-john-mashey-sgi-1995--lcqtgxlwl) ```json {"@context":"https://schema.org","@graph":[{"@type":"Organization","@id":"https://daily.dev/#organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180},"sameAs":["https://twitter.com/dailydotdev","https://github.com/dailydotdev","https://www.linkedin.com/company/daily-dev-ltd"]},{"@type":"WebSite","@id":"https://daily.dev/#website","url":"https://daily.dev","name":"daily.dev","publisher":{"@id":"https://daily.dev/#organization"},"potentialAction":{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https://daily.dev/search?q={search_term_string}"},"query-input":"required name=search_term_string"}}]} {"@context":"https://schema.org","@type":"TechArticle","headline":"The Prospects for 128 Bit Processors ( John Mashey SGI 1995)","url":"https://daily.dev/posts/the-prospects-for-128-bit-processors-john-mashey-sgi-1995--lcqtgxlwl","mainEntityOfPage":{"@type":"WebPage","@id":"https://daily.dev/posts/the-prospects-for-128-bit-processors-john-mashey-sgi-1995--lcqtgxlwl"},"datePublished":"2026-08-02T11:09:03.508Z","dateModified":"2026-08-02T11:09:53.602Z","description":"A 1995 Usenet post by John R. Mashey of Silicon Graphics analyzes when 128-bit processors might become necessary. Using DRAM density growth rates (4x every 3...","image":"https://media.daily.dev/image/upload/s--foaA6JGU--/f_auto/v1722860399/public/Placeholder%2004","thumbnailUrl":"https://media.daily.dev/image/upload/s--foaA6JGU--/f_auto/v1722860399/public/Placeholder%2004","isAccessibleForFree":true,"articleSection":"Hacker News","inLanguage":"en","publisher":{"@type":"Organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180}},"author":{"@type":"Organization","name":"Hacker News","logo":"https://media.daily.dev/image/upload/t_logo,f_auto/v1/logos/hn","url":"https://daily.dev/sources/hn"},"commentCount":1,"discussionUrl":"https://daily.dev/posts/the-prospects-for-128-bit-processors-john-mashey-sgi-1995--lcqtgxlwl","interactionStatistic":[{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":1},{"@type":"InteractionCounter","interactionType":{"@type":"CommentAction"},"userInteractionCount":1}],"keywords":"hardware","timeRequired":"PT8M"} {"@context":"https://schema.org","@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https://daily.dev"},{"@type":"ListItem","position":2,"name":"Hacker News","item":"https://daily.dev/sources/hn"},{"@type":"ListItem","position":3,"name":"The Prospects for 128 Bit Processors ( John Mashey SGI 1995)"}]} {"@context":"https://schema.org","@type":"WebPage","@id":"https://daily.dev/posts/the-prospects-for-128-bit-processors-john-mashey-sgi-1995--lcqtgxlwl","comment":[{"@type":"Comment","text":"And we already have RV128I. Unfortunately, supported only via experimental GCC and no OS.","datePublished":"2026-08-02T19:00:53.193Z","url":"https://daily.dev/posts/lcqtgxlWL#c-98EZ9QJ7h","author":{"@type":"Person","name":"Paweł Kraszewski","url":"https://daily.dev/pkraszewski","image":"https://avatars.githubusercontent.com/u/1206223?v=4"}}]} ```