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

91–100 of 199 posts

Re: The road to Zettalinux

#91

Post by vanderZwan »

munro wrote: post #86
vanderZwan wrote: post #79

Earlier quoted context omitted.

The value of Pi you mention was the one in the question, the one in the answer is: > For JPL's highest accuracy calculations, which are for interplanetary navigation, we use 3.141592653589793. Let's look at this a little more closely to understand why we don't use more decimal places. I think we can even see that there are no physically realistic calculations scientists ever perform for which it is necessary to inclu…

Lol I should RTFA ;D

Nah, just claim you were invoking Cunningham's Law ;)

Re: The road to Zettalinux

#92

Post by aidenn0 »

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…

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

Re: The road to Zettalinux

#93

Post by vanderZwan »

Beltiras wrote: post #88
vanderZwan wrote: post #79

Earlier quoted context omitted.

The value of Pi you mention was the one in the question, the one in the answer is: > For JPL's highest accuracy calculations, which are for interplanetary navigation, we use 3.141592653589793. Let's look at this a little more closely to understand why we don't use more decimal places. I think we can even see that there are no physically realistic calculations scientists ever perform for which it is necessary to inclu…

I have horrid memories of debugging I had to do to get some god-awful fourier transform to calculate with 15 digits of precision to fit a spec. It's right at the boundary where double-precision stops being deterministic. Worst debugging week of my life.

> stops being deterministic

I'm imagining the maths equivalent of Heisenbugs, is that correct?

Re: The road to Zettalinux

#94

Post by mort96 »

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…

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

Re: The road to Zettalinux

#95

Post by nicoburns »

creativemonkeys wrote: post #49
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…

I'm sure someone will come along and explain why I have no idea what I'm talking about, but so far my understanding is those names exist because of the difference in CPU word size. Typically "int" represents the natural word size for that CPU, which matches the register size as well, so 'int plus int' is as fast as addition can run by default, on a variety of CPUs. That's one reason chars and shorts are promoted to i…

That explains "int", but it doesn't explain short or long or long long. Rust has "usize" for the "int" case, and then fixed sizes for everything else, which works much better. If you want portable software, it's usually more important to know how many bits you have available for your calculation than it is to know how efficiently that calculation will happen.

Re: The road to Zettalinux

#96

Post by gjvc »

api wrote: post #39
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…

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…

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

Re: The road to Zettalinux

#97

Post by meisanother »

dragontamer wrote: post #74
throw10920 wrote: post #72

Earlier quoted context omitted.

That's what I was going to chime in with - you pay for that extra address width. Binary addition and multiplication latency is super-linear with regards to operand width. Larger pointers lead to more memory use, and memory access latency is non-constant with respect to size. It might make sense for large distributed systems to move to a 128-bit architecture, but I don't see any reason for consumer devices, at least w…

> Binary addition ... is super-linear with regards to operand width No its not. That's why Kogge-Stone's carry lookahead adder was such an amazing result. O(log(n)) latency with respect to operand width with O(n) total half-adders used. It may seem like its super-linear. But the power of prefix-sums leads to a spectacular and elegant solution. Kogge-stone (and the concept of prefix-sums) is one of the most important…

There's also something beautiful about seeing or creating a Kogge-Stone implementation on silicon.

I know it was one of the first time I thought to myself: this is not just a straightforward pipeline, yet it all follows such a beautifully geometrical interconnect pattern. Super fast, yet very elegant to layout.

Re: The road to Zettalinux

#98

Post by jabl »

munro wrote: post #77

There was a post awhile back from NASA saying how many digits of Pi they actually need [1]. import math pi = 31415926535897932384626433832795028841971693993751058209749445923078164062862089986280348253421170679821480865132823066470938446095505822317253594081284811174502841027019385211055596446229489549303819644288109756659334461284756482337867831652712019091456485669234603486104543266482133936072602491412737245870066…

Pi is a bit special because in order to get accurate argument reduction for trigonometric functions you needs lots of digits (IIRC ~1000 for double precision).

E.g. https://redirect.cs.umbc.edu/~phatak/645/supl/Ng-ArgReductio...

Re: The road to Zettalinux

#99

Post by lloeki »

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…

> 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’

Reminded me of Jeff Bonwick's answer to the following question about his 'boiling the oceans' quip related to ZFS being a "128 bit filesystem":

> 64 bits would have been plenty ... but then you can't talk out of your ass about boiling oceans then, can you?

Sadly his Sun hosted blog was eaten by the migration to Oracle, so thanks to the Internet Archive again:

http://web.archive.org/web/20061111054630/http://blogs.sun.c...

That one dives into some of the "handwaving" a bit:

https://hbfs.wordpress.com/2009/02/10/to-boil-the-oceans/

And that one goes into how much energy it would take to merely spin enough disks up:

https://www.reddit.com/r/DataHoarder/comments/71p8x4/reachin...

Re: The road to Zettalinux

#100

Post by dylan604 »

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…

>(comedy option: 32-bit int, 128-bit long, and 64-bit `unsigned middle`)

rather than unsigned middle, could we just call it malcom?

Post reply on HN