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

111–120 of 199 posts

Re: The road to Zettalinux

#111

Post by dylan604 »

wongarsu wrote: post #54
tayistay wrote: post #37

Is 128 bit the limit of what we would need? We use 128 bit UUIDs. 2^256 seems to be more than the number of atoms on Earth.

The article does talk about just making the pointer type used in syscalls 256 bit wide to "give room for any surprising future needs". The size of large networked disk arrays will grow beyond 64 bit addresses, but I don't think we will exceed 2^128 bits of storage of any size, for any practical application. Then again, there's probably people who thought the same about 32 bit addresses when we moved from 16bit to 32b…

>Then again, there's probably people who thought the same about 32 bit addresses when we moved from 16bit to 32bit addresses.

There's a fun "quote" about 384k being all anyone would ever need, so clearly everyone just needs to settle down and figure out how to refactor their code.

Re: The road to Zettalinux

#112

Post by hnuser123456 »

eterevsky wrote: post #76
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…

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.

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

Re: The road to Zettalinux

#113

Post by xxpor »

apaprocki wrote: post #42
mhh__ wrote: post #23

Earlier quoted context omitted.

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.

Itanium function pointers worked like that, so it could have been the new normal if IA64 wasn’t so crazy on the whole.

A Raymond Chen post about the function pointer craziness: https://devblogs.microsoft.com/oldnewthing/20150731-00/?p=90...

Re: The road to Zettalinux

#114

Post by MR4D »

eterevsky wrote: post #76
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…

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.

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-con...

Re: The road to Zettalinux

#115

Post by tcoppi »

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…

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.

Re: The road to Zettalinux

#117

Post by mikepurvis »

PaulDavisThe1st wrote: post #87
mikepurvis wrote: post #62

Earlier quoted context omitted.

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

Those are data types, not pointer values or filesystem offsets. Totally different thing.

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.

Re: The road to Zettalinux

#119

Post by PaulDavisThe1st »

mikepurvis wrote: post #117
PaulDavisThe1st wrote: post #87

Earlier quoted context omitted.

Those are data types, not pointer values or filesystem offsets. Totally different thing.

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.

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.

Re: The road to Zettalinux

#120

Post by krackout »

I think the article is very shortsighted. By 2035-40 we'll probably have memory only (RAM) computers massively available. No disks means no current OS capable of handling these computers. A change of paradigm needing new platforms and OSes.

These future OSes may be 128bit, but I don't think the current ones will make it to the transition.

Post reply on HN