8 ms·

The section about 128-bit pointers being necessary for expanded memory sizes is unconvincing -- 64 bits provides 16 EiB (16 x 1024 x 1024 x 1024 x 1 GiB), which

The section about 128-bit pointers being necessary for expanded memory sizes is unconvincing -- 64 bits provides 16 EiB (16 x 1024 x 1024 x 1024 x 1 GiB), which is the sort of address space you might need for byte-level addressing of a warehouse full of high-density HDDs. Memory sizes don't grow like they used to, and it's difficult to imagine what kind of new physics would let someone fit that many bytes into a machine that's practical to control with a single Linux kernel instance. CHERI is a much more interesting case, because it expands the definition of what a "pointer" is. Most low-level programmers think of pointers as just an address, but CHERI turns it into a sort of tuple of (address, bounds, permissions) -- every pointer is bounds-checked. The CHERI folks did some cleverness to pack that all into 128 bits, and I believe their demo platform uses 128-bit registers. The article also touches on the UNIX-y assumption that `long` is pointer-sized. This is well known (and well hated) by anyone that has to port software from UNIX to Windows, where `long` and `int` are the same size, and `long long` is pointer-sized. I'm firmly in the camp of using fixed-size integers but the Linux kernel uses `long` all over the place, and unless they plan to do a mass migration to `intptr_t` it's difficult to imagine a solution that would let the same C code support 32-, 64-, and 128-bit platforms. (comedy option: 32-bit int, 128-bit long, and 64-bit `unsigned middle`) The article also mentions Rust types as helpful, but Rust has its own problems with big pointers because they inadvisably merged `size_t`, `ptrdiff_t`, and `intptr_t` into the same type. They're working on adding equivalent symbols to the FFI module[0], but untangling `usize` might not be possible at this point. [0] https://github.com/rust-lang/rust/issues/88345 https://github.com/rust-lang/rust/issues/88345

mhh__ 4y ago
Systems for which pointers are not just integers have come and gone, sadly. Many mainframes had function pointers which were more like a struct than a pointer.
- masklinn 4y ago
  Technically that’s still pretty common on the software side, that’s what tagged pointers are. The ObjC/Swift runtime uses that for instance, the class pointer of an object also contains the refcount and a few flags.
  - mhh__ 4y ago
    Pointer tagging is still spiritually an integer (i.e. mask off the bits you guarantee the tags are in via alignment) versus (say) the pointer being multiple addresses into different bits of different types of memory and tags insert other stuff here.
    - masklinn 4y ago
      > Pointer tagging is still spiritually an integer No, pointer tagging is spiritually a packed structure. That can be a simple union (as it is in ocaml IIRC) but it can be a lot more e.g. the objc “non-pointer isa” ended up with 5 flags (excluding raw isa discriminant) and two additional non-pointer members of 19 and 9 bits. You mask things on and off to unpack the structure into component the system will accept. Nothing precludes using tagged pointers to discriminate between kinds and locations.
- apaprocki 4y ago
  Itanium function pointers worked like that, so it could have been the new normal if IA64 wasn’t so crazy on the whole.
  - xxpor 4y ago
    A Raymond Chen post about the function pointer craziness: https://devblogs.microsoft.com/oldnewthing/20150731-00/?p=90771 https://devblogs.microsoft.com/oldnewthing/20150731-00/?p=90...
dragontamer 4y ago
> it's difficult to imagine what kind of new physics would let someone fit that many bytes into a machine that's practical to control with a single Linux kernel instance. I nominally agree with most of your post. But I should note that modern systems seem to be moving towards a "one pointer space" for the entire cluster. For example, 8 GPUs + 2 CPUs would share the same virtual memory space (GPU#1 may take one slice, GPU#2 takes another, etc. etc.). This allows for RDMA (ie: mmap across Ethernet and other networking technologies). If everyone has the same address space, then you can share pointers / graphs between nodes and the underlying routing/ethernet software will be passing the data automatically between all systems. Its actually quite convenient. I don't know how the supercomputer software works, but I can imagine that 4000 CPUs + 16000 GPUs all sharing the same 64-bit address space.
- rwmj 4y ago
  Distributed Shared Memory is a thing, but I'm not sure how widely it is used. I found that it gives you all the coordination problems of threads in symmetric multiprocessing but at a larger scale and with much slower synchronisation. https://en.wikipedia.org/wiki/Distributed_shared_memory https://en.wikipedia.org/wiki/Distributed_shared_memory
  - dragontamer 4y ago
    https://en.wikipedia.org/wiki/Remote_direct_memory_access https://en.wikipedia.org/wiki/Remote_direct_memory_access Again, I'm not a supercomputer programmer. But the whitepapers often discuss RDMA. From my imagination, it sounds like any other "mmap". You, the programmer, just remembers that the mmap'd region is slower (since it is read/write to a Disk, rather than to RAM). Otherwise, you treat it "like RAM" from a programming perspective entirely for convenience sake. As long as you know my_mmap_region->next = foobar(); is a slow I/O operation pretending to be memory, you're fine. --------- Modern systems are converging upon this "single address space" programming model. PCIe 3.0 implements atomic operations and memory barriers, CXL is going to add cache-coherence over a remote / I/O interface. This means that all your memory_barriers / atomics / synchronization can be atomic-operations, and the OS will automatically translate these memory commands into the proper I/O level atomics/barriers to ensure proper synchronization. This is all very new, only within the past few years. But I think its one of the most exciting things about modern computer design. Yes, its slow. But its consistent and accurately modeled by all elements in the chain. Atomic-compare-and-swap over RDMA can allow for cache-coherent communications and synchronization over Ethernet, over GPUs, over CPUs, and any other accelerators sharing the same 64-bit memory space. Maybe not quite today, but soon. This technology already exists for PCIe 3.0 CPU+GPUs synchronization from 8 years ago (Shared Virtual Memory). Its exciting to see it extend out into more I/O devices.
cmrdporcupine 4y ago
Thanks for pointing out the `usize` ambiguity. It drives me nuts. I suspect it would make me even crazier if I was doing embedded with Rust right now and had to work with unsafe hardware pointers. (They also fail to distinguish an equivalent of `off_t` out, too. Not that I think that would have the same bit width ambiguities. But it seems odd to refer to offsets by a 'size')
api 4y ago
I can't imagine a single Linux kernel instance or single program controlling that much bus-local RAM, but as you say there are other uses. One use I can imagine is massively distributed computing where pointers can refer to things that are either local or remote. These could even map onto IPv6 addresses where the least significant 64 bits are a local machine pointer and the most significant 64 bits are the machine's /64. Of course the security aspect would have to be handled at the transport layer or this would have to be done on a private network. The latter would be more common since this would probably be a supercomputer thing. Still... I wonder if this needs CPU support or just compiler support? Would you get that much more performance from having this in hardware? I do really like how Rust has u128 native in the language. This permits a lot of nice things including efficient implementation of some cryptography and math stuff. C has irregular support for uint128_t but it's not really a first class citizen.
- gjvc 4y ago
  I can't imagine a single Linux kernel instance or single program controlling that much bus-local RAM, but as you say there are other uses. MS-DOS and 640K ...
  - api 4y ago
    The addressable size grows exponentially with more bits, not linearly. 2^64 is not twice as big as 2^32. It’s more than four billion times as big. 2^32 was only 65536 times as big as 2^16. Going past 2^64 bytes of local high speed RAM becomes a physics problem. I won’t say never but it would not just be an evolutionary change from what we have and a processor that could perform useful computations on that much data would be equally nuts. Just moving that much data on a bus of today would take too long to be useful, let alone computing on it.
    - gjvc 4y ago
      Thank you for the base-2 tutorial. I had no idea!
lostmsu 4y ago
So 64 bit address is only 1024 16TB HDDs? That number may go down quickly. There is a 100TB SSD already.
- ijlx 4y ago
  1024*1024 16TB HDDs, or 1,048,576.
- oofbey 4y ago
  1,000,000 drives at 16 TB each I think. Kilo is 10 bits. Mega 20. Gigs 30. Tera 40. 16TB is 44 bits. 1000* is another 10 bits so 54.
- infinityio 4y ago
  Not quite - 1024GiB is 1TiB, so it's 1024 x 1024 x 16TiB drives
- Beltiras 4y ago
  As my siblings are pointing out your error they are not addressing what you are saying. You are absolutely correct. It's conceivable within a few years to fit this much storage in one device (might be a full rack full of disks but still).
  - ksec 4y ago
    The highest density storage is currently 1PB in 1U, fitting 40PB in a Rack. We expect to reach 100PB in 2025, with some futuristic roadmap of 200PB in 2030, assuming we could yield those NAND. And a thousand layers NAND to reach 500PB in 2035. That is still an order of magnitude smaller than 16EiB. So no, not in a few years time.
    - guenthert 4y ago
      One thing is storage density, another is data transfer rate. Frontier's LustreFS based mind-boggling 700PB Orion storage subsystem writes at a similarly impressive 5TB/s [1]; so with a generous reading, it could potentially fill up in about 39h. Historically, disk density increased more rapidly than network bandwidth, which ultimately limits the performance of distributed file systems. If it takes weeks or months to write such enormous data set, then there will be only few use cases, if it takes years there will be none. [1] https://www.ornl.gov/news/frontier-supercomputer-debuts-worlds-fastest-breaking-exascale-barrier https://www.ornl.gov/news/frontier-supercomputer-debuts-worl...
anotherhue 4y ago
FYI Such memory tagging has a rich history https://en.wikipedia.org/wiki/Tagged_architecture https://en.wikipedia.org/wiki/Tagged_architecture
travisgriggs 4y ago
> (comedy option: 32-bit int, 128-bit long, and 64-bit `unsigned middle`) Or rather than keep moving the long goalpost, keep long at u64/i64 and add prolong(ed) for 128. Or we could keep long as the “nominal” register value, and introduce “short long” for 64. So many options.
eterevsky 4y ago
8 EiB of data (in case we want addresses using signed integers) is around 20 metric tons of micro-SD cards one TB each (assuming they weigh 2g each). This could probably fit in a single shipping container.
- hnuser123456 4y ago
  shipping container = 40x8x8ft microsd card = 15x11x1mm, 0.5g fits 437,503,976 cards = 379 EiB, costs $43.7B 219 metric tons 8 EiB ~ 10,000,000 TB = fills the shipping container 2.2% high or 56mm or 2 inches, 5 metric tons, costs $1B shipping containers are rated for up to 24 metric tons, so ~40 EiB $5B 10 inches of cards etc
  - bombcar 4y ago
    Don’t underestimate the bandwidth of a shipping container filled with SD cards.
- MR4D 4y ago
  But the cooling.... Seriously, that was great math you did there, and a neat way to think about volume. That's a standard shipping container [0], which is less than I thought it would be. [0] - https://www.mobilemodularcontainers.com/products/storage-container-rental/40ft https://www.mobilemodularcontainers.com/products/storage-con...
Spooky23 4y ago
Storage and interconnect specs are getting a lot faster. I could see a world where you treated an S3 scale storage system as a giant tiered addressable memory space. AS/400 systems sort of did something like that at a small scale.
aidenn0 4y ago
> ...which is the sort of address space you might need for byte-level addressing of a warehouse full of high-density HDDs So if you want to mmap() files stored in your datacenter warehouse, maybe you do need it?
mort96 4y ago
We couldn't introduce a new 'middle' keyword, but could we say 'int' is 32 bit, 'long' is 128 bit and 'short long' is 64 bit..?
dylan604 4y ago
>(comedy option: 32-bit int, 128-bit long, and 64-bit `unsigned middle`) rather than unsigned middle, could we just call it malcom?
tcoppi 4y ago
Even assuming you are correct on all these points ASLR is still an important use case and the effective security of current 64-bit address spaces is low.
retrac 4y ago
> 64 bits provides 16 EiB (16 x 1024 x 1024 x 1024 x 1 GiB), which is the sort of address space you might need for byte-level addressing of a warehouse full of high-density HDDs. Memory sizes don't grow like they used to An exabyte was an absolutely incomprehensible amount of memory, once. Nearly as incomprehensible as 4 gigabytes seemed, at one time. But as you note, 64 bits of addressable data can fit into a single warehouse now. Going by the historical rate of increase, $100 would buy about a petabyte of storage in 2040. Even presuming a major slowdown, we still start running into 64 bit addressing as a practical limit, perhaps sooner than you think.
torginus 4y ago
And there's another disadvantage to 128-bit pointers - memory size and alignment. It would follow that each struct field would become 16 byte-aligned, and pointers would bloat up as well, leading to even more memory consumption, especially in languages that favor pointer-heavy structures. This was a major counterargument against 64-bit x86, where the transition came out as a net zero in terms of performance, due to the hit of larger pointer sizes counterbalanced by ISA improvements such as more addressable registers. Many people in high-performance circles advocate using 32-bit array indices opposed to pointers, to counteract the cache pollution effects.
- akira2501 4y ago
  I figure the cache is going to be your largest disadvantage, and is the primary reason CPUs don't physically implement all address bits and why canonical addressing was required to get all this off the ground in the first place.
TheCondor 4y ago
It's very difficult to see normal computers that normal people use needing it any time soon, I agree. Frontier has 9.2PB of memory though, so that's 50bits for a petabyte and then 4 more bits, 54bits of memory addressability if we wanted to byte address it all. Looking at it that way, if super computers continue to be funded and grow like they have, we're getting shockingly close to 64bits of addressable memory. I don't know that that really means we need 128bit, 80 or 96bits buys a lot of time, but it's probably worth a little bit of thought. I don't know how many of you remember the pre-386 days. It was an effort to write interesting programs though, 512KB or 640KB of memory to work with but it was 16bit addressable and so you're writing code to manage segments and stuff, it's an extra degree of complexity and a pain to debug. 32bits seemed like a godsend when it happened. I imagine most of the dorks on here have ripped a blu-ray or transcoded a video image from somewhere, it's not super unusual to be dealing with a single file that cannot be represented as bytes with a 32bit pointer. It's all about cost and value, 64bits is still a staggering amount of memory but if the protein folding problems and climate models and what have you need 80bits of memory to represent the problem space, I would hope that the people building those don't also have to worry about the memory "shoe boxing" problems of yesteryear too.
musicale 4y ago
> CHERI is a much more interesting case It would be interesting to see something like this on x86 and ARM. I could imagine Apple implementing something similar.
green_on_black 4y ago
Personally, having just suffered the issue of uint64_t (unsigned long vs unsigned long long...): I prefer having "bit size" + "semantics" in the type, and that's it. If the hardware doesn't support it, fail horrendously or use an approximation/slower path, as specified by compiler options. In my opinion, developers should think about semantics first, optimization (device-specific or software) after (, unless you already know your device). I slightly disagree with JVM "int = 32bit" but they essentially are forcing their own "virtual hardware", so I can understand that. For portable native code... I can only say that I'm disappointed in uint64_t. But also that, maybe, the current Rust isn't the end-all be-all of portable types.

mhh__ 4y ago

Systems for which pointers are not just integers have come and gone, sadly. Many mainframes had function pointers which were more like a struct than a pointer.

masklinn 4y ago
Technically that’s still pretty common on the software side, that’s what tagged pointers are. The ObjC/Swift runtime uses that for instance, the class pointer of an object also contains the refcount and a few flags.
- mhh__ 4y ago
  Pointer tagging is still spiritually an integer (i.e. mask off the bits you guarantee the tags are in via alignment) versus (say) the pointer being multiple addresses into different bits of different types of memory and tags insert other stuff here.
  - masklinn 4y ago
    > Pointer tagging is still spiritually an integer No, pointer tagging is spiritually a packed structure. That can be a simple union (as it is in ocaml IIRC) but it can be a lot more e.g. the objc “non-pointer isa” ended up with 5 flags (excluding raw isa discriminant) and two additional non-pointer members of 19 and 9 bits. You mask things on and off to unpack the structure into component the system will accept. Nothing precludes using tagged pointers to discriminate between kinds and locations.
apaprocki 4y ago
Itanium function pointers worked like that, so it could have been the new normal if IA64 wasn’t so crazy on the whole.
- xxpor 4y ago
  A Raymond Chen post about the function pointer craziness: https://devblogs.microsoft.com/oldnewthing/20150731-00/?p=90771 https://devblogs.microsoft.com/oldnewthing/20150731-00/?p=90...

dragontamer 4y ago

> it's difficult to imagine what kind of new physics would let someone fit that many bytes into a machine that's practical to control with a single Linux kernel instance. I nominally agree with most of your post. But I should note that modern systems seem to be moving towards a "one pointer space" for the entire cluster. For example, 8 GPUs + 2 CPUs would share the same virtual memory space (GPU#1 may take one slice, GPU#2 takes another, etc. etc.). This allows for RDMA (ie: mmap across Ethernet and other networking technologies). If everyone has the same address space, then you can share pointers / graphs between nodes and the underlying routing/ethernet software will be passing the data automatically between all systems. Its actually quite convenient. I don't know how the supercomputer software works, but I can imagine that 4000 CPUs + 16000 GPUs all sharing the same 64-bit address space.

rwmj 4y ago
Distributed Shared Memory is a thing, but I'm not sure how widely it is used. I found that it gives you all the coordination problems of threads in symmetric multiprocessing but at a larger scale and with much slower synchronisation. https://en.wikipedia.org/wiki/Distributed_shared_memory https://en.wikipedia.org/wiki/Distributed_shared_memory
- dragontamer 4y ago
  https://en.wikipedia.org/wiki/Remote_direct_memory_access https://en.wikipedia.org/wiki/Remote_direct_memory_access Again, I'm not a supercomputer programmer. But the whitepapers often discuss RDMA. From my imagination, it sounds like any other "mmap". You, the programmer, just remembers that the mmap'd region is slower (since it is read/write to a Disk, rather than to RAM). Otherwise, you treat it "like RAM" from a programming perspective entirely for convenience sake. As long as you know my_mmap_region->next = foobar(); is a slow I/O operation pretending to be memory, you're fine. --------- Modern systems are converging upon this "single address space" programming model. PCIe 3.0 implements atomic operations and memory barriers, CXL is going to add cache-coherence over a remote / I/O interface. This means that all your memory_barriers / atomics / synchronization can be atomic-operations, and the OS will automatically translate these memory commands into the proper I/O level atomics/barriers to ensure proper synchronization. This is all very new, only within the past few years. But I think its one of the most exciting things about modern computer design. Yes, its slow. But its consistent and accurately modeled by all elements in the chain. Atomic-compare-and-swap over RDMA can allow for cache-coherent communications and synchronization over Ethernet, over GPUs, over CPUs, and any other accelerators sharing the same 64-bit memory space. Maybe not quite today, but soon. This technology already exists for PCIe 3.0 CPU+GPUs synchronization from 8 years ago (Shared Virtual Memory). Its exciting to see it extend out into more I/O devices.

cmrdporcupine 4y ago

Thanks for pointing out the `usize` ambiguity. It drives me nuts. I suspect it would make me even crazier if I was doing embedded with Rust right now and had to work with unsafe hardware pointers. (They also fail to distinguish an equivalent of `off_t` out, too. Not that I think that would have the same bit width ambiguities. But it seems odd to refer to offsets by a 'size')

api 4y ago

I can't imagine a single Linux kernel instance or single program controlling that much bus-local RAM, but as you say there are other uses. One use I can imagine is massively distributed computing where pointers can refer to things that are either local or remote. These could even map onto IPv6 addresses where the least significant 64 bits are a local machine pointer and the most significant 64 bits are the machine's /64. Of course the security aspect would have to be handled at the transport layer or this would have to be done on a private network. The latter would be more common since this would probably be a supercomputer thing. Still... I wonder if this needs CPU support or just compiler support? Would you get that much more performance from having this in hardware? I do really like how Rust has u128 native in the language. This permits a lot of nice things including efficient implementation of some cryptography and math stuff. C has irregular support for uint128_t but it's not really a first class citizen.

gjvc 4y ago
I can't imagine a single Linux kernel instance or single program controlling that much bus-local RAM, but as you say there are other uses. MS-DOS and 640K ...
- api 4y ago
  The addressable size grows exponentially with more bits, not linearly. 2^64 is not twice as big as 2^32. It’s more than four billion times as big. 2^32 was only 65536 times as big as 2^16. Going past 2^64 bytes of local high speed RAM becomes a physics problem. I won’t say never but it would not just be an evolutionary change from what we have and a processor that could perform useful computations on that much data would be equally nuts. Just moving that much data on a bus of today would take too long to be useful, let alone computing on it.
  - gjvc 4y ago
    Thank you for the base-2 tutorial. I had no idea!

lostmsu 4y ago

So 64 bit address is only 1024 16TB HDDs? That number may go down quickly. There is a 100TB SSD already.

ijlx 4y ago
1024*1024 16TB HDDs, or 1,048,576.
oofbey 4y ago
1,000,000 drives at 16 TB each I think. Kilo is 10 bits. Mega 20. Gigs 30. Tera 40. 16TB is 44 bits. 1000* is another 10 bits so 54.
infinityio 4y ago
Not quite - 1024GiB is 1TiB, so it's 1024 x 1024 x 16TiB drives
Beltiras 4y ago
As my siblings are pointing out your error they are not addressing what you are saying. You are absolutely correct. It's conceivable within a few years to fit this much storage in one device (might be a full rack full of disks but still).
- ksec 4y ago
  The highest density storage is currently 1PB in 1U, fitting 40PB in a Rack. We expect to reach 100PB in 2025, with some futuristic roadmap of 200PB in 2030, assuming we could yield those NAND. And a thousand layers NAND to reach 500PB in 2035. That is still an order of magnitude smaller than 16EiB. So no, not in a few years time.
  - guenthert 4y ago
    One thing is storage density, another is data transfer rate. Frontier's LustreFS based mind-boggling 700PB Orion storage subsystem writes at a similarly impressive 5TB/s [1]; so with a generous reading, it could potentially fill up in about 39h. Historically, disk density increased more rapidly than network bandwidth, which ultimately limits the performance of distributed file systems. If it takes weeks or months to write such enormous data set, then there will be only few use cases, if it takes years there will be none. [1] https://www.ornl.gov/news/frontier-supercomputer-debuts-worlds-fastest-breaking-exascale-barrier https://www.ornl.gov/news/frontier-supercomputer-debuts-worl...

anotherhue 4y ago

FYI Such memory tagging has a rich history https://en.wikipedia.org/wiki/Tagged_architecture https://en.wikipedia.org/wiki/Tagged_architecture

travisgriggs 4y ago

> (comedy option: 32-bit int, 128-bit long, and 64-bit `unsigned middle`) Or rather than keep moving the long goalpost, keep long at u64/i64 and add prolong(ed) for 128. Or we could keep long as the “nominal” register value, and introduce “short long” for 64. So many options.

eterevsky 4y ago

8 EiB of data (in case we want addresses using signed integers) is around 20 metric tons of micro-SD cards one TB each (assuming they weigh 2g each). This could probably fit in a single shipping container.

hnuser123456 4y ago
shipping container = 40x8x8ft microsd card = 15x11x1mm, 0.5g fits 437,503,976 cards = 379 EiB, costs $43.7B 219 metric tons 8 EiB ~ 10,000,000 TB = fills the shipping container 2.2% high or 56mm or 2 inches, 5 metric tons, costs $1B shipping containers are rated for up to 24 metric tons, so ~40 EiB $5B 10 inches of cards etc
- bombcar 4y ago
  Don’t underestimate the bandwidth of a shipping container filled with SD cards.
MR4D 4y ago
But the cooling.... Seriously, that was great math you did there, and a neat way to think about volume. That's a standard shipping container [0], which is less than I thought it would be. [0] - https://www.mobilemodularcontainers.com/products/storage-container-rental/40ft https://www.mobilemodularcontainers.com/products/storage-con...

Spooky23 4y ago

Storage and interconnect specs are getting a lot faster. I could see a world where you treated an S3 scale storage system as a giant tiered addressable memory space. AS/400 systems sort of did something like that at a small scale.

aidenn0 4y ago

> ...which is the sort of address space you might need for byte-level addressing of a warehouse full of high-density HDDs So if you want to mmap() files stored in your datacenter warehouse, maybe you do need it?

mort96 4y ago

We couldn't introduce a new 'middle' keyword, but could we say 'int' is 32 bit, 'long' is 128 bit and 'short long' is 64 bit..?

dylan604 4y ago

>(comedy option: 32-bit int, 128-bit long, and 64-bit `unsigned middle`) rather than unsigned middle, could we just call it malcom?

tcoppi 4y ago

Even assuming you are correct on all these points ASLR is still an important use case and the effective security of current 64-bit address spaces is low.

retrac 4y ago

> 64 bits provides 16 EiB (16 x 1024 x 1024 x 1024 x 1 GiB), which is the sort of address space you might need for byte-level addressing of a warehouse full of high-density HDDs. Memory sizes don't grow like they used to An exabyte was an absolutely incomprehensible amount of memory, once. Nearly as incomprehensible as 4 gigabytes seemed, at one time. But as you note, 64 bits of addressable data can fit into a single warehouse now. Going by the historical rate of increase, $100 would buy about a petabyte of storage in 2040. Even presuming a major slowdown, we still start running into 64 bit addressing as a practical limit, perhaps sooner than you think.

torginus 4y ago

And there's another disadvantage to 128-bit pointers - memory size and alignment. It would follow that each struct field would become 16 byte-aligned, and pointers would bloat up as well, leading to even more memory consumption, especially in languages that favor pointer-heavy structures. This was a major counterargument against 64-bit x86, where the transition came out as a net zero in terms of performance, due to the hit of larger pointer sizes counterbalanced by ISA improvements such as more addressable registers. Many people in high-performance circles advocate using 32-bit array indices opposed to pointers, to counteract the cache pollution effects.

akira2501 4y ago
I figure the cache is going to be your largest disadvantage, and is the primary reason CPUs don't physically implement all address bits and why canonical addressing was required to get all this off the ground in the first place.

TheCondor 4y ago

It's very difficult to see normal computers that normal people use needing it any time soon, I agree. Frontier has 9.2PB of memory though, so that's 50bits for a petabyte and then 4 more bits, 54bits of memory addressability if we wanted to byte address it all. Looking at it that way, if super computers continue to be funded and grow like they have, we're getting shockingly close to 64bits of addressable memory. I don't know that that really means we need 128bit, 80 or 96bits buys a lot of time, but it's probably worth a little bit of thought. I don't know how many of you remember the pre-386 days. It was an effort to write interesting programs though, 512KB or 640KB of memory to work with but it was 16bit addressable and so you're writing code to manage segments and stuff, it's an extra degree of complexity and a pain to debug. 32bits seemed like a godsend when it happened. I imagine most of the dorks on here have ripped a blu-ray or transcoded a video image from somewhere, it's not super unusual to be dealing with a single file that cannot be represented as bytes with a 32bit pointer. It's all about cost and value, 64bits is still a staggering amount of memory but if the protein folding problems and climate models and what have you need 80bits of memory to represent the problem space, I would hope that the people building those don't also have to worry about the memory "shoe boxing" problems of yesteryear too.

musicale 4y ago

> CHERI is a much more interesting case It would be interesting to see something like this on x86 and ARM. I could imagine Apple implementing something similar.

green_on_black 4y ago

Personally, having just suffered the issue of uint64_t (unsigned long vs unsigned long long...): I prefer having "bit size" + "semantics" in the type, and that's it. If the hardware doesn't support it, fail horrendously or use an approximation/slower path, as specified by compiler options. In my opinion, developers should think about semantics first, optimization (device-specific or software) after (, unless you already know your device). I slightly disagree with JVM "int = 32bit" but they essentially are forcing their own "virtual hardware", so I can understand that. For portable native code... I can only say that I'm disappointed in uint64_t. But also that, maybe, the current Rust isn't the end-all be-all of portable types.