And do this again in 2050 to get to 256-bit computing?
And then 512-bit around 2070?
Can we not play it save and immediately jump to for 65536-bit :)
We could call it 16-bit-bit.
The road to Zettalinux
181–190 of 199 posts
Re: The road to Zettalinux
#182Earlier quoted context omitted.
I thought up a few ways to visualize 2^64 unique items: - You could give every ant on Earth ~920 unique IDs without any collisions - You could give unique IDs for every brain neuron for all ~215 million people in Brazil - The ocean contains about 20 × (2^64) gallons of water (3.5267 × 10^20 gallons total) - There are between 100-400 billion stars in the Milky Way, so you could assign each star between 46,000,000–184,…
Those are great examples
I think multiplying (1000 unique identifiers) isn’t fair but I like the gallons.
Re: The road to Zettalinux
#183Earlier quoted context omitted.
I thought up a few ways to visualize 2^64 unique items: - You could give every ant on Earth ~920 unique IDs without any collisions - You could give unique IDs for every brain neuron for all ~215 million people in Brazil - The ocean contains about 20 × (2^64) gallons of water (3.5267 × 10^20 gallons total) - There are between 100-400 billion stars in the Milky Way, so you could assign each star between 46,000,000–184,…
There are only ~368 grains of sand per ant?
The common claim that there are ~7.5E18 (~2.5 × 2⁶⁴) grains of sand seems to originate from this back-of-the-envelope calculation:
https://web.archive.org/web/19990117001023/http://www2.hawai...
It takes only beach sand into account, and of course there's a lot of guessing involved. It could be easily off by many orders of magnitude.
Re: The road to Zettalinux
#184Earlier quoted context omitted.
So 64 bit address is only 1024 16TB HDDs? That number may go down quickly. There is a 100TB SSD already.
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).
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.
Re: The road to Zettalinux
#185Earlier quoted context omitted.
Just because you can refer to the identity of a thing anywhere in the cluster doesn't mean it can't also be memory-safe, capability-based, and just an RPC.
Then why make said identity a fixed size number pretending to be a flat address space, instead of some other type of key?
For example, reads (when allowed) might just be transparent RAM accesses.
I'm not advocating 128-bit pointers, or saying they're useful or realistic. I'm just saying, what if.
Re: The road to Zettalinux
#186Earlier quoted context omitted.
Then why make said identity a fixed size number pretending to be a flat address space, instead of some other type of key?
For example, reads (when allowed) might just be transparent RAM accesses. I'm not advocating 128-bit pointers, or saying they're useful or realistic. I'm just saying, what if.
The issue is latency. If you don’t want to care if the read or write will take 10ns or 10000ns, then that can work, assuming a flat permission structure too. Latency is a fundamental restriction for any computer that is > zero size, and the larger the ‘computer’ (data center), the more noticeable it is.
(For that matter, what happens when different segments of memory have complex access controls? What about needing to retry to failures like network partitions that don’t happen in a normal memory space?)
If latency matters, which it usually does, then you need some kind of memory access hierarchy, copying things back and forth, etc. and then you’ll almost certainly need a library of some kind to manage all this, prefetch from a slow range of memory and populate some of your fast local memory, etc.
At that point, we’ve done a lot of work, and are still pretending there is no network or the like, even though it’s there. It isn’t free, anyway. We’d also need checksums, cross network/fabric/access error handling, etc.
And with 128 bits, we could also use something like IPv6 with the lower 64 bits being byte address hah.
Re: The road to Zettalinux
#187Earlier quoted context omitted.
For example, reads (when allowed) might just be transparent RAM accesses. I'm not advocating 128-bit pointers, or saying they're useful or realistic. I'm just saying, what if.
The issue is latency. If you don’t want to care if the read or write will take 10ns or 10000ns, then that can work, assuming a flat permission structure too. Latency is a fundamental restriction for any computer that is > zero size, and the larger the ‘computer’ (data center), the more noticeable it is. (For that matter, what happens when different segments of memory have complex access controls? What about needing t…
Data centers are already doing "disaggregated memory" (page out to remote RAM), as it's been faster than local disk for years now (or at least was in the pre-NVMe world).
The HPC world is all about RDMA to direct-access their huge data sets, and likely hyperscaler clouds are starting to do that too.
The latency gap is just treated as yet another layer of the cache model.
And we already have error correction for local RAM.
Re: The road to Zettalinux
#188Earlier quoted context omitted.
The issue is latency. If you don’t want to care if the read or write will take 10ns or 10000ns, then that can work, assuming a flat permission structure too. Latency is a fundamental restriction for any computer that is > zero size, and the larger the ‘computer’ (data center), the more noticeable it is. (For that matter, what happens when different segments of memory have complex access controls? What about needing t…
Data centers are already doing "disaggregated memory" (page out to remote RAM), as it's been faster than local disk for years now (or at least was in the pre-NVMe world). The HPC world is all about RDMA to direct-access their huge data sets, and likely hyperscaler clouds are starting to do that too. The latency gap is just treated as yet another layer of the cache model. And we already have error correction for local…
Which as you note, NVME and the latest PCI generations turns on it’s head.
Those were due to bottlenecks that don’t exist anymore, and even in your example were even then only emergency measures due to local resource shortages.
ECC is also not reliable/sufficient in the face of issues that arrive when networks start playing their part.
Re: The road to Zettalinux
#189Earlier quoted context omitted.
The AS/400 and iSeries also use 128-bit pointers. 128-bit would be useful for multiple pointers already in common use such as ZFS and IP6 addresses. I expect it will the last hop for a long time.
In the context of the AS/400's single-level store architecture the 128-bit pointers make a lot of sense, too.
Only 64 of those 128 bits are the actual address. The first byte indicates the type of object the pointer points to. The next seven bytes are (for some pointer types) used to encode security permissions (capabilities); for other types they are just reserved (all zeroes). So taking up 128 bits is more about capability-based security and type safety than the single-level store per se; the single-level store would have worked about as well with only 64-bit pointers. There is also a 129th bit (tag bit) which helps detect unsafe pointer modification. (The tag bit is stored using ECC memory’s extra bits for storing the error correction, which happen to have one spare bit per every 16 bytes.)
Conceptually similar to ARM Morello/CHERI’s 129 bit pointers; although that is a much more sophisticated implementation than IBM 38/400/i.
Re: The road to Zettalinux
#190Earlier quoted context omitted.
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).
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.
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-worl...