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

191–199 of 199 posts

Re: The road to Zettalinux

#191

Post by warinukraine »

ghoward wrote: post #136

It would be sad if we, as an industry, do not take this opportunity to create a better OS. First, we should decide whether to have a microkernel or a monolithic kernel. I think the answer is obvious: microkernel. This is much safer, and seL4 has shown that performance need not suffer too much. Next, we should start by acknowledging the chicken-and-egg problem, especially with drivers. We will need drivers. So let's r…

Would you like to mention what kind of expertise you have to state that a microkernel is obviously better, and in what sense it's better? And also explain how is it that microkernels already exist and no one cares? Especially the ones older than Linux?

Re: The road to Zettalinux

#192

Post by arthur2e5 »

mhh__ wrote: post #26
Tsarbomb wrote: post #20

Earlier quoted context omitted.

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

For what is worth, 256 / log2(10) is around 77, while the observable universe is estimated to have anywhere from 10^78 to 10^82 atoms. An 256-bit address space, if fully utilized, would produce Asimov’s AC from The Last Question.

More realistically though, we would throw away at least half that length like how we are handing out /64 blocks to everyone on IPv6.

Re: The road to Zettalinux

#193

Post by josefx »

mpweiher wrote: post #108
kuratkull wrote: post #57

Earlier quoted context omitted.

Good luck seeing your performance drop off a very sharp cliff if you start using larger numbers than your CPU can fit into a single register.

Well, in those case other languages fail. Either silently with overflows, usually leading to security exploits, or by crashing. So in either case you are betting that these cases are somewhere between rare and non-existent, particularly for your core/performance intensive code. Being somewhat slower, probably in very isolated contexts (60-62 bits is quite a bit to overflow), but always correct seems like the better t…

How many languages actually take advantage of the fact that they could get more performance out of "small" register sized integers? You tend to lose a lot of performance to arbitrary sized integers in most languages even if your inputs are small.

> but always correct seems like the better tradeoff.

Not if you are dealing with time constraints. Glitchy output isn't good, but locking up the system because some buggy code path is trying to allocate a 10 GB integer can be worse.

Re: The road to Zettalinux

#194

Post by guenthert »

guenthert wrote: post #190
ksec wrote: post #184

Earlier quoted context omitted.

The highest density storage is currently 1PB in 1U, fitting 40PB in a Rack. We expect to reach 100PB in 2025, with some futuristic roadmap of 200PB in 2030, assuming we could yield those NAND. And a thousand layers NAND to reach 500PB in 2035. That is still an order of magnitude smaller than 16EiB. So no, not in a few years time.

One thing is storage density, another is data transfer rate. Frontier's LustreFS based mind-boggling 700PB Orion storage subsystem writes at a similarly impressive 5TB/s [1]; so with a generous reading, it could potentially fill up in about 39h. Historically, disk density increased more rapidly than network bandwidth, which ultimately limits the performance of distributed file systems. If it takes weeks or months to…

> network bandwidth, which ultimately limits the performance of distributed file systems.

Oops, that's nonsense. I had my coffee now...

Re: The road to Zettalinux

#195

Post by dragontamer »

adgjlsfhk1 wrote: post #179
dragontamer wrote: post #103

Earlier quoted context omitted.

Kogge-stone's O(Log2(n)) latency complexity might as well be constant. The difference between 64-bit and 128-bit is the difference between 6 and 7. There's going to be no issues implementing a 128-bit adder. None at all.

a 10% latency hit on addition would definitely be noticable. that's roughly 1.5 years of IPC improvements at the current rate of CPU progress.

That's really not how that works.

Transistors have a "latency" measured in picoseconds, not nanoseconds.

A 128-bit adder will have a latency of 1-clock cycle, a 10% increase from a 64-bit adder of latency of 1-clock cycle. Aka: it doesn't matter cause it'd almost certainly fit inside of the clock cycle of modern CPUs.

Re: The road to Zettalinux

#196

Post by mpweiher »

josefx wrote: post #193
mpweiher wrote: post #108

Earlier quoted context omitted.

Well, in those case other languages fail. Either silently with overflows, usually leading to security exploits, or by crashing. So in either case you are betting that these cases are somewhere between rare and non-existent, particularly for your core/performance intensive code. Being somewhat slower, probably in very isolated contexts (60-62 bits is quite a bit to overflow), but always correct seems like the better t…

How many languages actually take advantage of the fact that they could get more performance out of "small" register sized integers? You tend to lose a lot of performance to arbitrary sized integers in most languages even if your inputs are small. > but always correct seems like the better tradeoff. Not if you are dealing with time constraints. Glitchy output isn't good, but locking up the system because some buggy co…

> How many languages actually take advantage of the fact that they could get more performance out of "small" register sized integers?

Er...all of them? I am not aware of one that uses growable integers as their default integer representation that does not use some form of tagged pointer optimisation.

> Glitchy output isn't good

Hmm...understating the problem here just a tad.

"In 2021, they ranked 12th in the updated Common Weakness Enumeration (CWE) list of the most common flaws, bugs, faults, and other errors in either hardware or software. The team behind the list ranked integer overflows just after “Missing Authentication for Critical Function”, due to the severity and prevalence of integer overflows."

https://www.comparitech.com/blog/information-security/intege...

> Some buggy code path is trying to allocate a 10 GB integer can be worse

Hmmm...overstating the problem here just a tad. Not even sure how you'd manage that, given that that would be an integer with 4 billion digits.

Re: The road to Zettalinux

#197

Post by krackout »

alpb wrote: post #121
krackout wrote: post #120

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.

There are plenty of OSes today capable of booting and running from RAM. Pretty sure we wouldn't be burning all the prominent OSes for something like that.

Forget the concept of booting. Boot transfers the kernel OS from disk to RAM. No such thing would be needed on a RAM memory only computer.

Re: The road to Zettalinux

#198

Post by gjvc »

api wrote: post #104
gjvc wrote: post #96

Earlier quoted context omitted.

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

The addressable size grows exponentially with more bits, not linearly. 2^64 is not twice as big as 2^32. It’s more than four billion times as big. 2^32 was only 65536 times as big as 2^16. Going past 2^64 bytes of local high speed RAM becomes a physics problem. I won’t say never but it would not just be an evolutionary change from what we have and a processor that could perform useful computations on that much data w…

Thank you for the base-2 tutorial. I had no idea!

Re: The road to Zettalinux

#199

Post by ghoward »

warinukraine wrote: post #191
ghoward wrote: post #136

It would be sad if we, as an industry, do not take this opportunity to create a better OS. First, we should decide whether to have a microkernel or a monolithic kernel. I think the answer is obvious: microkernel. This is much safer, and seL4 has shown that performance need not suffer too much. Next, we should start by acknowledging the chicken-and-egg problem, especially with drivers. We will need drivers. So let's r…

Would you like to mention what kind of expertise you have to state that a microkernel is obviously better, and in what sense it's better? And also explain how is it that microkernels already exist and no one cares? Especially the ones older than Linux?

Smaller Trusted Computing Base (TCB). Easier to audit and if necessary, prove correct.

I want better security in computing more than I want performance.

Post reply on HN