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

161–170 of 199 posts

Re: The road to Zettalinux

#161

Post by dredmorbius »

nequo wrote: post #156
dredmorbius wrote: post #153

Earlier quoted context omitted.

jaimehrubiks stated unequivocally without substantiation that "Somebody asked before to please not share lwn's SubscriberLinks". LWN's founder & editor has repeatedly stated otherwise, hasn't criticised the practice, and participates in the practice himself, as recently as three months ago. SubscriberLinks are tracked by the LWN account sharing them. Abuse can be managed through LWN directly should that become an iss…

Corbet repeatedly used the word “occasionally,” sometimes even with emphasis. What I’m saying is that the current situation is that most of the for-pay content of LWN is available on HN which is at odds either with his wish that it be occasional or with my understanding of English.

Most of those submissions die in the queue.

I'd set a 20-comment limit to the search I presented for a reason. At present, the 30 results shown go back over 7 months. That's roughly a significant submission per week.

Contrasting a search for "lwn.net" alone in submissions, the first page of results (sorted by date, again, 30 results) only goes back 3 weeks (22 days). But most of those get little activity --- some upvotes, and a few with many comments, but, in a third search sorted by popularity over the past month,

https://hn.algolia.com/?dateRange=pastMonth&page=0&prefix=tr...>

Ten of those meet or beat my 20-comment threshold, 20 don't. And note that 20 comments isn't especially significant, 4 submissions exceed 100 comments.

lwn SubscriberLink & > 20 comments, by date: https://hn.algolia.com/?dateRange=all&page=0&prefix=true&que...>

All "lwn.net" for past month: https://hn.algolia.com/?dateRange=pastMonth&page=0&prefix=tr...>

Data:

Comments: 189 94 155 254 153 29 46 10 14 20 13 12 89 10 21 1 8 0 1 1 0 2 0 0 0 0 2 1 1 0

Points: 306 271 254 240 166 114 109 89 62 58 53 45 42 39 37 30 20 7 5 5 5 4 4 4 4 4 3 3 3 3

I'm not saying that the concern doesn't exist. But ultimately, it's LWN's to address. The constant admonishments to not share links seem to fall into tangential annoyances and generic tangents, both against HN guidelines: https://news.ycombinator.com/newsguidelines.html>

I'd suggest leaving this to Corbet and dang.

Re: The road to Zettalinux

#162

Post by jupp0r »

"The problem now is that there is no 64-bit type in the mix. One solution might be to "ask the compiler folks" to provide a __int64_t type. But a better solution might just be to switch to Rust types, where i32 is a 32-bit, signed integer, while u128 would be unsigned and 128 bits. This convention is close to what the kernel uses already internally, though a switch from "s" to "i" for signed types would be necessary. Rust has all the types we need, he said, it would be best to just switch to them."

Does anybody know why they don't use the existing fixed size integer types [1] from C99 ie uint64_t etc and define a 128 bit wide type on top of that (which will also be there in C23 IIRC)?

My own kernel dev experience is pretty rusty at this point (pun intended), but in the last decade of writing cross platform (desktop, mobile) userland C++ code I advocated exclusively for using fixed width types (std::uint32_t etc) as well as constants (UINT32_MAX etc).

Re: The road to Zettalinux

#164

Post by jandrewrogers »

zozbot234 wrote: post #159
c-linkage wrote: post #150

Earlier quoted context omitted.

Distributed Memory Access is just another kind of Non-Uniform Memory Access, which is Yet Another Leaky Abstraction. Specifically, if you care about performance at all you now have to worry about where in RAM your data lives . Caring about where in memory your data lives is different from dealing with cache or paging. Programmers have to plan ahead to keep frequently accessed data in fast RAM, and infrequently access…

> And once you extend "memory" outside the chassis, you'll have to design your application with the expectation that any memory access could fail because a network failure means the memory is no longer accessible. You have to deal with these things anyway in any kind of distributed setting. What this kind of location-independence via SSI really buys you is the ability to scale the exact same workloads down to a singl…

I've written code for a few different large-scale SSI architectures. The shared-memory programming model is less efficient than explicit message passing in practice because it is much more difficult to optimize. The underlying infrastructure is essentially converged at this point, so performance mostly comes down to the usability of the programming model.

The marketing for SSI was that it was simple because programmers would not have to learn explicit message passing. Unfortunately, people that buy supercomputers tend to care about performance, so designing a supercomputer that is difficult to optimize misses the point. In real code, the only way to make them perform well was to layer topology-aware message passing on top of the shared memory model. At which point you should've just bought a message passing architecture.

There is only one type of large-scale SSI architecture that is able to somewhat maintain the illusion of uniform shared memory -- hardware latency-hiding e.g. barrel processors. If programmers have difficulty writing scalable code with message passing, then they definitely are going to struggle with this. These systems use a completely foreign programming paradigm that looks deceptively like vanilla C++. Exceptional efficient, and companies design new ones every few years, but without programmers that grok how to write optimal code they aren't much use.

Re: The road to Zettalinux

#165

Post by bombcar »

hnuser123456 wrote: post #112
eterevsky wrote: post #76

Earlier quoted context omitted.

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

Don’t underestimate the bandwidth of a shipping container filled with SD cards.

Re: The road to Zettalinux

#166

Post by kmeisthax »

Aqueous wrote: post #122

If we're going to go for 128- why not just go for 256-? that way we won't have to do this again for a while. or better yet, design a new abstraction for not having to hard-code the limit of the pointer size but instead allow it to be extensible as more addressable space becomes a reality, instead of having to transition over and over. is this even possible? if it is, shouldn't we head in that direction?

The problem with variable-sized pointers is that...

1. Any abstraction you could make will have worse performance than a fixed-size machine pointer

2. In order to support any kind of variably-sized type you need machine pointers to begin with, and those will always be fixed-size because variable size is even harder to support in hardware than native code

And furthermore going straight to 256 has its own problems. Each time you double the pointer size you also significantly increase the size of structures with a lot of pointers. V8 notably uses "pointer compression" - i.e. using 32-bit offsets instead of 64-bit pointers, because it never needs >4GB of JavaScript objects at once and JS objects are very pointer-ridden.

There's two forces at play here: pointers need to be small enough to embed in any data structure and large enough to address the entire working set of the program. Larger pointers are not inherently better[0], and neither are smaller pointers. It's a balancing act.

[0] ASLR, PAC, and CHERI are exceptions, as mentioned in the original article.

Re: The road to Zettalinux

#167

Post by tuatoru »

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…

> On one hand The IBM System/38 used 128 bit pointers in the 1970s, despite having a 48 bit physical address bus.

And the original processor was 24 bits, then it was upgraded to 36 bits (not a typo: 36 bits), and then to POWER 64 bits.

(When that last happened, it was re-badged AS/400. Later, marketing renamed the AS/400 to iSeries, and then to IBM i, without changing anything significant. Still uses Power CPUs, AFAIK).

For users, upgrades were a slightly longer than usual backup and restore.

What's the hard part here?

Re: The road to Zettalinux

#168

Post by vlovich123 »

rektide wrote: post #148
vlovich123 wrote: post #140

Earlier quoted context omitted.

Let's say you have nodes that have 10 TiB of RAM in them. You then need 1.6M nodes (not CPUs, but actual boxes) to use up 64bits of address space. It seems like the motivation is to continue to enable Top500 machines to scale. This wouldn't be coming to a commercial cloud offering for a long time.

Why limit yourself to in-memory storage? I'd definitely assume we have all our storage content memory mapped onto our cluster too, in this world. People have been building exabyte (1M gigabytes) scale datacenters since well before 2010, and 16 exabytes, the current Linux limit according to the most upvoted post here, isn't that much more inconceivable. Having more space available usually opens up more interesting pos…

Maybe. You are paying a significant performance penalty for ALL compute to provide that abstraction though.

Re: The road to Zettalinux

#169

Post by tuatoru »

PaulHoule wrote: post #128
lloeki wrote: post #99

Earlier quoted context omitted.

> 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? Sa…

One absolute limit of computation is that it takes (1/2) kT of energy to delete one bit of information where k is the Boltzmann constant and T is the temperature. Let T = 300° K (room temperature) I multiplied that by 2¹²⁸, and got 1.41×10¹⁸ J of energy. 1 ton of TNT is 4.2×10¹² J, so that is a 335 kiloton explosion worth of energy just to boot. That's not impossible, that much heat is extracted from a nuclear reacto…

> 1.41×10¹⁸ J of energy.

Used over the course of a year, that is a constant 44.4 GW. Less than Bitcoin uses already

Re: The road to Zettalinux

#170

Post by fragmede »

Eduard wrote: post #134
bdn_ wrote: post #132

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

Well no. See there's this one ant, Jeff, that's hogging them all for itself, so each ant only gets 50 grains grains of sand.
Post reply on HN