Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The road to Zettalinux

lwn.net

Post reply on HN
Print view View original

21–30 of 199 posts

Re: The road to Zettalinux

#21

Post by masklinn »

LinkLink wrote: post #6

For reference 2^64 = ~10^19.266 I don't think this is unreasonable at all, its unlikely that computers will largely stay the same in the coming years. I believe we'll see many changes to how things like mass addressing of data and computing resources is done. Right now our limitations in these regards are addressed by distributed computing and databases, but in a hyper-connected world there may come a time when such…

I don’t know it seems excessive to me. I could see the cold storage maybe, with spanning storage pools (by my reckoning there were 10TB drives in 2016 and the largest now are 20, so 16 years from now should be 320 if it keeps doubling, which is 5 orders of magnitude below still).

> Right now our limitations in these regards are addressed by distributed computing and databases, but in a hyper-connected world there may come a time when such huge address space could actually be used.

Used at the core of the OS itself? How do you propose to beat the speed of light exactly?

Because you don’t need a zettabyte-compatible kernel to run a distributed database (or even file system, see ZFS), trying to DMA things on the other side of the planet sounds like the worst possible experience.

Hell, our current computers right now are not even close to 64 bit address spaces. The baseline is 48 bits, and x86 and ARM are in the process of extending the address space (to 57 bits for x86, and 52 for ARM).

Re: The road to Zettalinux

#22

Post by fluoridation »

mpweiher wrote: post #11
masklinn wrote: post #7

Earlier quoted context omitted.

Legacy, there’s lots of dumb stuff in C. As you note, in modern languages the rule is generally to have fixed-size integers. Though I think there are portability issues concerns, that world is mostly gone (it remains in some corners of computing e.g. dsps) but if you’re only using fixed-size integers what do you do when a platform doesn’t have that size? With a more flexible scheme, you have less issues there, howeve…

> in modern languages the rule is generally to have fixed-size integers. Modern languages have unlimited size integers :-) "Modern" as in "since at least the 80s, more likely 70s".

Good luck using those to specify the data layout of a network packet.

Re: The road to Zettalinux

#23

Post by mhh__ »

jmillikin wrote: post #18

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 mach…

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.

Re: The road to Zettalinux

#24

Post by mhh__ »

PaulHoule wrote: post #2

On one hand The IBM System/38 used 128 bit pointers in the 1970s, despite having a 48 bit physical address bus. These were used to manage persistent objects on disk or network with unique ids a lot like uuids. On the other hand, filling out a 64 bit address space looks tough. I struggled to find something of the same magnitude of 2^64 and I got ‘number of iron atoms in an iron filing’, From a nanotechnological point…

IBM i is still in development and also has a 128 bit pointer.

Re: The road to Zettalinux

#25

Post by raverbashing »

masklinn wrote: post #7
Blikkentrekker wrote: post #3

> How would this look in the kernel? Wilcox had originally thought that, on a 128-bit system, an int should be 32 bits, long would be 64 bits, and both long long and pointer types would be 128 bits. But that runs afoul of deeply rooted assumptions in the kernel that long has the same size as the CPU's registers, and that long can also hold a pointer value. The conclusion is that long must be a 128-bit type. Can anyon…

Legacy, there’s lots of dumb stuff in C. As you note, in modern languages the rule is generally to have fixed-size integers. Though I think there are portability issues concerns, that world is mostly gone (it remains in some corners of computing e.g. dsps) but if you’re only using fixed-size integers what do you do when a platform doesn’t have that size? With a more flexible scheme, you have less issues there, howeve…

> Legacy, there’s lots of dumb stuff in C.

Yes, this, so much this

Who cares what an 'int' or a 'long' is. Except for things like the size of a pointer, it's better if you know exactly what you're working with.

Re: The road to Zettalinux

#26

Post by mhh__ »

Tsarbomb wrote: post #20
LinkLink wrote: post #6

For reference 2^64 = ~10^19.266 I don't think this is unreasonable at all, its unlikely that computers will largely stay the same in the coming years. I believe we'll see many changes to how things like mass addressing of data and computing resources is done. Right now our limitations in these regards are addressed by distributed computing and databases, but in a hyper-connected world there may come a time when such…

Not agreeing or disagreeing for the most part, but in 2009 all of the prerequisite technology for cryptocurrency existed: general purpose computers for the average person, accessible internet, cryptographic algorithms and methods, and cheap storage. For 256 bit computers, we need entirely new CPU architectures and updated ISAs for not just x86/AMD64, but for other archs increasing in popularity such as ARM and even R…

256 bits in the case of a worldwide mega-computer would be such a huge departure from current architectures and more importantly latency-numbers that we can barely even speculate about it.

It may be of note that hypothetically one can have a soft-ISA 128 bit virtual address (a particularly virtual virtual address) which is JITed down into a narrower physical address by the operating system. This is as far as I'm aware how IBM i works.

Re: The road to Zettalinux

#28

Post by jmillikin »

LinkLink wrote: post #6

For reference 2^64 = ~10^19.266 I don't think this is unreasonable at all, its unlikely that computers will largely stay the same in the coming years. I believe we'll see many changes to how things like mass addressing of data and computing resources is done. Right now our limitations in these regards are addressed by distributed computing and databases, but in a hyper-connected world there may come a time when such…

  > It's an unlikely hypothetical but imagine if fiber ran everywhere,
  > and all computers seamlessly worked together sharing computer power
  > as needed. Even 256 bits wouldn't be out of the question then.
You could do this today with 196 bits (128-bit IPv6 address, 64-bit local pointer). Take a look at RDMA, which could be summarized as "every computer's RAM might be any computer's RAM".

The question is whether such an address makes sense for the Linux kernel. If your hyper-converged distributed program wants to call `read()`, does the pointer to the buffer really need to be able to identify any machine in the world? Maybe it's enough for the kernel to use 64-bit local pointers only, and have a different address mechanism for remote storage.

Re: The road to Zettalinux

#29

Post by masklinn »

mhh__ wrote: post #23
jmillikin wrote: post #18

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 mach…

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.

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.

Re: The road to Zettalinux

#30

Post by mhh__ »

PaulHoule wrote: post #8
Blikkentrekker wrote: post #3

> How would this look in the kernel? Wilcox had originally thought that, on a 128-bit system, an int should be 32 bits, long would be 64 bits, and both long long and pointer types would be 128 bits. But that runs afoul of deeply rooted assumptions in the kernel that long has the same size as the CPU's registers, and that long can also hold a pointer value. The conclusion is that long must be a 128-bit type. Can anyon…

C dates back to a time when the 8 bit byte didn’t have 100% market share.

C still (I think, C23 may have finally killed support*) supports architectures like clearpath mainframes which have a 36 bit word, 9 bit byte, 36 (IIRC) bit data pointer and a 81 bit function pointer.

The changes to the arithmetic rules mean you can't have sign-magnitude or 1s complement anymore IIRC

Post reply on HN