4 ms·

How long is a tick/tock cycle? A few years? 3 * 7 = 21. So we'd need to prep for going beyond 64bit some time before 2035? Which chimes with the quote At histor

How long is a tick/tock cycle? A few years? 3 * 7 = 21. So we'd need to prep for going beyond 64bit some time before 2035? Which chimes with the quote At historic rates of growth, it is possible that greater than 64 bits of address space might be required before 2030 that 'unwind' kindly gives in a sister comment. Seems like good forward planning but a little premature, no? These features must come at some cost. Surely you could have a re-vamp sometime around 2025?

vidarh 12y ago
Why in the world would you plan a new architecture today, that will take years - easily a decade or more - to gain enough traction to be interesting, only to have to re-vamp it shortly afterwards? We have off the shelf x86 machines today that can fit enough memory to use about 43 bits to address it (at least in theory - depending on DIMM availability; 1TB/2TB is trivially available on the other hand). Now add in size of readily viable storage arrays or even network file systems and expect some people to want to be able to memory map "unreasonably" large files, and suddenly we're into 50+ bits today. It'd seem crazy to me if someone were to start planning a new processor architecture today without planning for addresses greater than 64 bits.
- JoeAltmaier 12y ago
  64 bits is a hell of a lot larger than 48 bits. You could make the argument that humanity will never need more than 64 bits, no matter how many trillions of years our race exists and uses computers.
  - valarauca1 12y ago
    64ints you mean a 64bit signed dated is massive. Not 64bit address space, 64bits is only ~18exabytes of information. I'm very sure we'll find a need to load that much data into ram eventually.
    - JoeAltmaier 12y ago
      No I meant 64-bit pointers are large enough to handle every piece of memory every manufactured in human history.
      - TheLoneWolfling 12y ago
        And at the time of the first 32-bit processors you could potentially say the same about 32-bit pointers.
  - audunw 12y ago
    You dont necessarily have to use every bit of that address space, for a large address space to be useful. The Mill architecture for instance, requires each program to live in its own area of the address space, as this helps make the caches faster (TLB dont have to come before cache). This still leaves a comfortable amount of space left in the 64bit address space.. today. But maybe not in the future
    - JoeAltmaier 12y ago
      Still unlikely there will be enough apps to matter? Every single bit in an address is a doubling of available space, remember.
      - vidarh 12y ago
        The number of apps needed for it to matter can be measured in the single digits for there to be demand to pay for it, assuming it's the right single digits... It's quite possible - even likely - that low end systems will not be 128 bits anytime soon. 8 bit microprocessors are still selling in large volumes for embedded use. But we're about to see 64 bit entering phones this year, because it is becoming necessary, or at least more convenient than not. All the evidence is that we're not heading towards a slowdown in growth in storage requirements anytime soon. If anything, the existence of super-computers that are spread over huge clusters instead of being a single, tightly integrated system indicates that there is some level of demand for systems several orders of magnitude larger than the current largest off the shelf systems even today, at the right price. The top end of the market have increased by at least 10 bits over the last 11-12 years alone. At the current storage growth rates, we'll hit the 64 bit limit on single server systems sometime in the next 10-20 years when factoring in memory mapped IO; sooner for single-system-image clusters.
        JoeAltmaier 12y ago
        I don't know. That address space is very much larger than all the storage every produced in human history.
  - vidarh 12y ago
    We are looking at 50+ bits today if you want to mmap the largest off the shelf files you'll be able to store on local disk on some of the servers available even from the average system integrator. 47-48bits of physical RAM for shared-memory setups from companies like SGI, possibly more. And it's not that big a leap: 15 years ago, I worked mostly on systems with <1GB RAM, and where to get a decent performance 1TB+ disk array, we were looking at a fridge sized monstrosity. Today, my laptop has more than that. Even my phone is closing in: 1GB RAM + 64GB storage (even some mid range Chinese phones today advertise support for 256GB SD cards, so it is already obsolete) 15 years before that again - 1985 - my machine had 64KB of RAM and 176KB floppies. A couple of years later I finally got 1MB of RAM and a 20MB HD. So I don't consider it unreasonable to assume that we'll have systems in the 1PB RAM range and 1000+ PB storage range by 2030. That's about 50 bits for physical memory alone, or more like 60 bits to memory map that much secondary storage. That's assuming no shared memory eating address space for example. For most people, it will not be that relevant for a few more years, just like it took several years from 32bit became an issue on servers until it mattered for home computers, and like how 32 bit is first now becoming an issue for mobile. But think about that for a second: We don't need 64 bit for our mobile phones. We do nothing on them we couldn't find ways to shoehorn into a 32bit address space for decades to come. But going to 64bit is convenient. It lets us shove 8GB or 16GB RAM or more into future systems and not have to think so much about memory efficiency. So we're going there. Thus the idea that "humanity will never need more than 64 bits" I think is pretty much ridiculous, because it puts things on its head: It's not that we will "need" it, but that we will easily find ways of making use of it if we can. E.g. direct addressing all your storage is convenient in all kinds of ways. Storing all your home videos uncompressed, unedited, in 8K resolutions, in 3D, at a higher frame rate, becomes convenient when there's enough storage. Being able to write apps that can mmap multi PB monstrosity video projects instead of worrying about disk buffering becomes convenient when it's possible to do it. It's not that long since I used to consider databases of a few hundred MB big. Now I throw around multi GB databases on a daily basis, and I know they are small for a lot of people, who deal with individual databases in the TB or PB size without blinking.

vidarh 12y ago

Why in the world would you plan a new architecture today, that will take years - easily a decade or more - to gain enough traction to be interesting, only to have to re-vamp it shortly afterwards? We have off the shelf x86 machines today that can fit enough memory to use about 43 bits to address it (at least in theory - depending on DIMM availability; 1TB/2TB is trivially available on the other hand). Now add in size of readily viable storage arrays or even network file systems and expect some people to want to be able to memory map "unreasonably" large files, and suddenly we're into 50+ bits today. It'd seem crazy to me if someone were to start planning a new processor architecture today without planning for addresses greater than 64 bits.

JoeAltmaier 12y ago
64 bits is a hell of a lot larger than 48 bits. You could make the argument that humanity will never need more than 64 bits, no matter how many trillions of years our race exists and uses computers.
- valarauca1 12y ago
  64ints you mean a 64bit signed dated is massive. Not 64bit address space, 64bits is only ~18exabytes of information. I'm very sure we'll find a need to load that much data into ram eventually.
  - JoeAltmaier 12y ago
    No I meant 64-bit pointers are large enough to handle every piece of memory every manufactured in human history.
    - TheLoneWolfling 12y ago
      And at the time of the first 32-bit processors you could potentially say the same about 32-bit pointers.
- audunw 12y ago
  You dont necessarily have to use every bit of that address space, for a large address space to be useful. The Mill architecture for instance, requires each program to live in its own area of the address space, as this helps make the caches faster (TLB dont have to come before cache). This still leaves a comfortable amount of space left in the 64bit address space.. today. But maybe not in the future
  - JoeAltmaier 12y ago
    Still unlikely there will be enough apps to matter? Every single bit in an address is a doubling of available space, remember.
    - vidarh 12y ago
      The number of apps needed for it to matter can be measured in the single digits for there to be demand to pay for it, assuming it's the right single digits... It's quite possible - even likely - that low end systems will not be 128 bits anytime soon. 8 bit microprocessors are still selling in large volumes for embedded use. But we're about to see 64 bit entering phones this year, because it is becoming necessary, or at least more convenient than not. All the evidence is that we're not heading towards a slowdown in growth in storage requirements anytime soon. If anything, the existence of super-computers that are spread over huge clusters instead of being a single, tightly integrated system indicates that there is some level of demand for systems several orders of magnitude larger than the current largest off the shelf systems even today, at the right price. The top end of the market have increased by at least 10 bits over the last 11-12 years alone. At the current storage growth rates, we'll hit the 64 bit limit on single server systems sometime in the next 10-20 years when factoring in memory mapped IO; sooner for single-system-image clusters.
      - JoeAltmaier 12y ago
        I don't know. That address space is very much larger than all the storage every produced in human history.
- vidarh 12y ago
  We are looking at 50+ bits today if you want to mmap the largest off the shelf files you'll be able to store on local disk on some of the servers available even from the average system integrator. 47-48bits of physical RAM for shared-memory setups from companies like SGI, possibly more. And it's not that big a leap: 15 years ago, I worked mostly on systems with <1GB RAM, and where to get a decent performance 1TB+ disk array, we were looking at a fridge sized monstrosity. Today, my laptop has more than that. Even my phone is closing in: 1GB RAM + 64GB storage (even some mid range Chinese phones today advertise support for 256GB SD cards, so it is already obsolete) 15 years before that again - 1985 - my machine had 64KB of RAM and 176KB floppies. A couple of years later I finally got 1MB of RAM and a 20MB HD. So I don't consider it unreasonable to assume that we'll have systems in the 1PB RAM range and 1000+ PB storage range by 2030. That's about 50 bits for physical memory alone, or more like 60 bits to memory map that much secondary storage. That's assuming no shared memory eating address space for example. For most people, it will not be that relevant for a few more years, just like it took several years from 32bit became an issue on servers until it mattered for home computers, and like how 32 bit is first now becoming an issue for mobile. But think about that for a second: We don't need 64 bit for our mobile phones. We do nothing on them we couldn't find ways to shoehorn into a 32bit address space for decades to come. But going to 64bit is convenient. It lets us shove 8GB or 16GB RAM or more into future systems and not have to think so much about memory efficiency. So we're going there. Thus the idea that "humanity will never need more than 64 bits" I think is pretty much ridiculous, because it puts things on its head: It's not that we will "need" it, but that we will easily find ways of making use of it if we can. E.g. direct addressing all your storage is convenient in all kinds of ways. Storing all your home videos uncompressed, unedited, in 8K resolutions, in 3D, at a higher frame rate, becomes convenient when there's enough storage. Being able to write apps that can mmap multi PB monstrosity video projects instead of worrying about disk buffering becomes convenient when it's possible to do it. It's not that long since I used to consider databases of a few hundred MB big. Now I throw around multi GB databases on a daily basis, and I know they are small for a lot of people, who deal with individual databases in the TB or PB size without blinking.