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

151–160 of 199 posts

Re: The road to Zettalinux

#151

Post by FuriouslyAdrift »

dragontamer wrote: post #68
rwmj wrote: post #43

Earlier quoted context omitted.

Distributed Shared Memory is a thing, but I'm not sure how widely it is used. I found that it gives you all the coordination problems of threads in symmetric multiprocessing but at a larger scale and with much slower synchronisation. https://en.wikipedia.org/wiki/Distributed_shared_memory

https://en.wikipedia.org/wiki/Remote_direct_memory_access Again, I'm not a supercomputer programmer. But the whitepapers often discuss RDMA. From my imagination, it sounds like any other "mmap". You, the programmer, just remembers that the mmap'd region is slower (since it is read/write to a Disk, rather than to RAM). Otherwise, you treat it "like RAM" from a programming perspective entirely for convenience sake. As…

RDMA is used heavily in SMB3 file systems for Microsoft HyperV failover clusters.

Re: The road to Zettalinux

#152

Post by nequo »

dredmorbius wrote: post #146
jaimehrubiks wrote: post #116

Quoted post unavailable.

As long as the posting of subscriber links in places like this is occasional, I believe it serves as good marketing for LWN - indeed, every now and then, I even do it myself. We just hope that people realize that we run nine feature articles every week, all of which are instantly accessible to LWN subscribers. -- Jonathan Corbet, LWN founder & and grumpy editor in chief https://news.ycombinator.com/item?id=1966033 >…

Whether the posting of subscriber links is “occasional” as of late is debatable.[1] Most of LWN’s paywalled content is posted on HN.

[1] https://news.ycombinator.com/item?id=32926853

Re: The road to Zettalinux

#153

Post by dredmorbius »

nequo wrote: post #152
dredmorbius wrote: post #146

Earlier quoted context omitted.

As long as the posting of subscriber links in places like this is occasional, I believe it serves as good marketing for LWN - indeed, every now and then, I even do it myself. We just hope that people realize that we run nine feature articles every week, all of which are instantly accessible to LWN subscribers. -- Jonathan Corbet, LWN founder & and grumpy editor in chief https://news.ycombinator.com/item?id=1966033 >…

Whether the posting of subscriber links is “occasional” as of late is debatable.[1] Most of LWN’s paywalled content is posted on HN. [1] https://news.ycombinator.com/item?id=32926853

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 issue. Whether or not that's occurred in the past I've no idea, but the capability still exists and is permitted.

No link substantiating jamiehrubiks' assertion seems to have been supplied yet.

I'm going to take Corbet's authority on this.

Re: The road to Zettalinux

#154

Post by tonnydourado »

bdn_ wrote: post #132
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…

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

Re: The road to Zettalinux

#156

Post by nequo »

dredmorbius wrote: post #153
nequo wrote: post #152

Earlier quoted context omitted.

Whether the posting of subscriber links is “occasional” as of late is debatable.[1] Most of LWN’s paywalled content is posted on HN. [1] https://news.ycombinator.com/item?id=32926853

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.

Re: The road to Zettalinux

#157

Post by akira2501 »

torginus wrote: post #143
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…

And there's another disadvantage to 128-bit pointers - memory size and alignment. It would follow that each struct field would become 16 byte-aligned, and pointers would bloat up as well, leading to even more memory consumption, especially in languages that favor pointer-heavy structures. This was a major counterargument against 64-bit x86, where the transition came out as a net zero in terms of performance, due to t…

I figure the cache is going to be your largest disadvantage, and is the primary reason CPUs don't physically implement all address bits and why canonical addressing was required to get all this off the ground in the first place.

Re: The road to Zettalinux

#158

Post by ManuelKiessling »

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?

No wonder I keep reading about sand shortages.

Re: The road to Zettalinux

#159

Post by zozbot234 »

c-linkage wrote: post #150
dragontamer wrote: post #68

Earlier quoted context omitted.

https://en.wikipedia.org/wiki/Remote_direct_memory_access Again, I'm not a supercomputer programmer. But the whitepapers often discuss RDMA. From my imagination, it sounds like any other "mmap". You, the programmer, just remembers that the mmap'd region is slower (since it is read/write to a Disk, rather than to RAM). Otherwise, you treat it "like RAM" from a programming perspective entirely for convenience sake. As…

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 single cluster or even a single node when feasible, while keeping an efficient shared-memory programming model instead of doing slow explicit message passing. It seems like a pretty big simplification.

Re: The road to Zettalinux

#160

Post by TheCondor »

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…

It's very difficult to see normal computers that normal people use needing it any time soon, I agree. Frontier has 9.2PB of memory though, so that's 50bits for a petabyte and then 4 more bits, 54bits of memory addressability if we wanted to byte address it all. Looking at it that way, if super computers continue to be funded and grow like they have, we're getting shockingly close to 64bits of addressable memory.

I don't know that that really means we need 128bit, 80 or 96bits buys a lot of time, but it's probably worth a little bit of thought.

I don't know how many of you remember the pre-386 days. It was an effort to write interesting programs though, 512KB or 640KB of memory to work with but it was 16bit addressable and so you're writing code to manage segments and stuff, it's an extra degree of complexity and a pain to debug. 32bits seemed like a godsend when it happened. I imagine most of the dorks on here have ripped a blu-ray or transcoded a video image from somewhere, it's not super unusual to be dealing with a single file that cannot be represented as bytes with a 32bit pointer.

It's all about cost and value, 64bits is still a staggering amount of memory but if the protein folding problems and climate models and what have you need 80bits of memory to represent the problem space, I would hope that the people building those don't also have to worry about the memory "shoe boxing" problems of yesteryear too.

Post reply on HN