4 ms·

> Matthew Wilcox took the stage to make the point that 64 bits may turn out to be too few — and sooner than we think Let's think critically for a moment. I gre

> Matthew Wilcox took the stage to make the point that 64 bits may turn out to be too few — and sooner than we think Let's think critically for a moment. I grew up in the 1980s and 1990s, when we all craved more and more powerful computers. I even remember the years when each generation of video games was marketed as 8-bit, 16-bit, 32-bit, ect. BUT: We're hitting a point where, for what we use computers for, they're powerful enough. I don't think I'll ever need to carry a 128-bit phone in my pocket, nor do I think I'll need a 128-bit web browser, nor do I think I'll need a 128-bit web server. (See other posts about how 64-bits can address massive amounts of memory.) Will we need 128-bit computing? I'm sure someone will find a need. But let's not assume they'll need an operating system designed in the 1990s for use cases that we can't imagine today.

wongarsu 4y ago
We are talking about the OS kernel that supports 4096 CPU cores. The companies who pay their engineers to do linux kernel development tend to be the same ones that have absurd needs.
- p_l 4y ago
  And that's not enough to boot on some platforms that linux runs on (even with amd64 ISA) unless one partitions the computer into smaller cpu counts
uluyol 4y ago
Supercomputers? Rack-scale computing? See some of the work being done with RDMA and "far memory".
- gwbas1c 4y ago
  Yes... And do you need that in the same kernel that goes into your phone and your web server?
mikepurvis 4y ago
IMO there's an important distinction to be made between high-bit addressing and high-bit computing. Like, no one has enough memory to need more than 64 bits for addressing, and that is likely to remain the case for the foreseeable future. However, 128- and 256-bit values are commonly used in domains like graphics, audio, and so-on, where you need to apply long chains of transformations and filters, but retain as much of the underlying dynamic range as possible.
- PaulDavisThe1st 4y ago
  Those are data types, not pointer values or filesystem offsets. Totally different thing.
  - mikepurvis 4y ago
    Is that strictly the definition, that the bit-width of a processor refers only to its native pointer size? I know it's hardly a typical or modern example, but the N64 had just 4MB of memory (8MB with the expansion pack). It most certainly didn't need 64-bit pointers to address that pittance, so it was a "64 bit processor" largely for the purposes of register/data size.
    - PaulDavisThe1st 4y ago
      Not so much a definition as where the problem lies. If the thing that can refer to a memory address changes size, there are very different problems than will arise if the size of "an integer" changes. You could easily imagine a processor that can only address an N-bit address space, but can trivially do arithmetic on N*M bit integers or floating point values. And obviously the other way around, too. In general, I think "N bit processor" tends to refer to the data type sizing, but since those primitive data types will tend to fit into the same registers that are used to hold pointers, it ends up describing addressing too.
jerf 4y ago
I think the argument for 128-bits being necessary strictly for routing memory in a single "computer" is fairly weak. We're already seeing the plateauing of memory sizes nowadays; what was exponentially in reach within just a couple of decades exponentially recedes from us as our progress goes from exponential to polynomial. But the argument that we need more than 64 bit capability for a lot of other reasons in conjunction with memory addressability is I think very strong. A lot of very powerful and safe techniques become available if we can tag pointers with more than a bit squeezed out here and a bit squeezed out there. I could even see hard-coding the CPU to, say, look at 80 bits as an address and then us the remaining 48 for tagging of various sorts. There's precedent, and 80 bits is an awful lot of addressible memory; that's a septillion+ addressible bytes, by the time we need more than that, if we do, our future selves can deal with that. (It is good to look ahead a decade or two and make reasonable preparations, as this article does; it is hubris to start trying to look ahead 50 years or a century.)

wongarsu 4y ago

We are talking about the OS kernel that supports 4096 CPU cores. The companies who pay their engineers to do linux kernel development tend to be the same ones that have absurd needs.

p_l 4y ago
And that's not enough to boot on some platforms that linux runs on (even with amd64 ISA) unless one partitions the computer into smaller cpu counts

uluyol 4y ago

Supercomputers? Rack-scale computing? See some of the work being done with RDMA and "far memory".

gwbas1c 4y ago
Yes... And do you need that in the same kernel that goes into your phone and your web server?

mikepurvis 4y ago

IMO there's an important distinction to be made between high-bit addressing and high-bit computing. Like, no one has enough memory to need more than 64 bits for addressing, and that is likely to remain the case for the foreseeable future. However, 128- and 256-bit values are commonly used in domains like graphics, audio, and so-on, where you need to apply long chains of transformations and filters, but retain as much of the underlying dynamic range as possible.

PaulDavisThe1st 4y ago
Those are data types, not pointer values or filesystem offsets. Totally different thing.
- mikepurvis 4y ago
  Is that strictly the definition, that the bit-width of a processor refers only to its native pointer size? I know it's hardly a typical or modern example, but the N64 had just 4MB of memory (8MB with the expansion pack). It most certainly didn't need 64-bit pointers to address that pittance, so it was a "64 bit processor" largely for the purposes of register/data size.
  - PaulDavisThe1st 4y ago
    Not so much a definition as where the problem lies. If the thing that can refer to a memory address changes size, there are very different problems than will arise if the size of "an integer" changes. You could easily imagine a processor that can only address an N-bit address space, but can trivially do arithmetic on N*M bit integers or floating point values. And obviously the other way around, too. In general, I think "N bit processor" tends to refer to the data type sizing, but since those primitive data types will tend to fit into the same registers that are used to hold pointers, it ends up describing addressing too.

jerf 4y ago

I think the argument for 128-bits being necessary strictly for routing memory in a single "computer" is fairly weak. We're already seeing the plateauing of memory sizes nowadays; what was exponentially in reach within just a couple of decades exponentially recedes from us as our progress goes from exponential to polynomial. But the argument that we need more than 64 bit capability for a lot of other reasons in conjunction with memory addressability is I think very strong. A lot of very powerful and safe techniques become available if we can tag pointers with more than a bit squeezed out here and a bit squeezed out there. I could even see hard-coding the CPU to, say, look at 80 bits as an address and then us the remaining 48 for tagging of various sorts. There's precedent, and 80 bits is an awful lot of addressible memory; that's a septillion+ addressible bytes, by the time we need more than that, if we do, our future selves can deal with that. (It is good to look ahead a decade or two and make reasonable preparations, as this article does; it is hubris to start trying to look ahead 50 years or a century.)