Live data from Hacker News

I/O Is Faster Than CPU – Let’s Partition Resources and Eliminate OS Abstractions [pdf]

penberg.org

71–80 of 291 posts

Re: I/O Is Faster Than CPU – Let’s Partition Resources and Eliminate OS Abstractions [pdf]

#71
post #30

Earlier quoted context omitted.

The point of normalization is logical consistency, not IO optimization.

Sure. But the point of (early) NoSQL was IO optimization, not logical consistency.

This one gets hard to pick into, given how nebulous the term NoSQL is.

One could probably argue, quite convincingly, that the point of truly early NoSQL was that SQL hadn't been invented yet.

Re: I/O Is Faster Than CPU – Let’s Partition Resources and Eliminate OS Abstractions [pdf]

#72
post #57

Earlier quoted context omitted.

Amen to that. Unix was never a good design, and now is severely out of date. We can no longer afford to hack around it.

Would you care to elaborate why Unix, in your opinion, was never a good design?

It was re-written on an unsafe language that completely disregarded what has happened outside Bell Labs since 1961, at Burroughs, IBM, MIT, Xerox and other research cathedrals.

It only took off thanks to Bell Labs being forbidden to sell it, so it got offered for a symbolic price, alongside source code to major universities, which then decided to build on top, instead of paying OS street prices.

Had UNIX been sold in the same vein as other mainframe OSes and no one would be talking about whatever quality it might have had.

Re: I/O Is Faster Than CPU – Let’s Partition Resources and Eliminate OS Abstractions [pdf]

#73
post #19

Strictly speaking, the sentence "I/O is faster then CPU", aka "memory access is faster then computations" is nonsense, because it compares apples with bananas. One could probably say "transfering x data between CPU and SSD is faster then performing the computation f(x) on the CPU", where still f remains undefined.

You're misreading the article. Its subject is that because of the way IO stacks have been built CPUs are becoming the bottleneck in IO , this is an issue for both network and non-volatile storage IO e.g. > a 40 GbE NIC can receive a cache line sized packet every 5 ns, but the last level cache (LLC) access latency is already up to 15 ns, which means a single LLC access can already prevent the OS from keeping up with a…

Latency ≠ throughput

Re: I/O Is Faster Than CPU – Let’s Partition Resources and Eliminate OS Abstractions [pdf]

#74

We need entirely new OS abstractions to replace the dated notions of hierarchical file systems built around the metaphor of file cabinets, I/O as streams of bytes, terminals, process hierarchy. Essentially, say goodbye to the Unix model after 50 years. It would open up an entirely new world of software experimentation and craftsmanship.

One idea I've been throwing around is to replace files with HTTP resources; everything is a resource. Effectively Plan9s idea, but the time might be right.

I don't know much about the OS and designs, but is that similar to how Redox is approaching it with "everything is a url"[0]?

[0]https://doc.redox-os.org/book/design/urls_schemes_resources....

Re: I/O Is Faster Than CPU – Let’s Partition Resources and Eliminate OS Abstractions [pdf]

#75

We need entirely new OS abstractions to replace the dated notions of hierarchical file systems built around the metaphor of file cabinets, I/O as streams of bytes, terminals, process hierarchy. Essentially, say goodbye to the Unix model after 50 years. It would open up an entirely new world of software experimentation and craftsmanship.

Amen to that. Unix was never a good design, and now is severely out of date. We can no longer afford to hack around it.

UNIX was a great design for a wide range of people. FOr example, multiple domains of science were transformed because UNIX made it easy to implement microcomputers for data collection on realtime data and share the resulting software among a pool of other researchers.

Re: I/O Is Faster Than CPU – Let’s Partition Resources and Eliminate OS Abstractions [pdf]

#76
post #21

At least in database kernels, we noticeably reached this threshold around five years ago with typical server hardware. This is an interesting computer science problem in that virtually all of our database literature is based on the presumption that I/O is much slower than CPU. If you cleanroom a database kernel design based on the assumption that I/O performance is not the bottleneck, you end up with an architecture…

What was the situation like before SSDs? Were the fastest hard drives at the time (15k rpm?) faster than the fastest CPUs?

Individually no, collectively (i.e. storage arrays) yes.

Re: I/O Is Faster Than CPU – Let’s Partition Resources and Eliminate OS Abstractions [pdf]

#77

Earlier quoted context omitted.

Are you aware of any efforts by existing databaes or entirely new databases built with this realization in mind?

http://www.datomic.com

Datomic is just a Prolog logical layer on top of traditional RDBMS (e.g. Postgres, H2, etc).

Re: I/O Is Faster Than CPU – Let’s Partition Resources and Eliminate OS Abstractions [pdf]

#78
post #61

We need entirely new OS abstractions to replace the dated notions of hierarchical file systems built around the metaphor of file cabinets, I/O as streams of bytes, terminals, process hierarchy. Essentially, say goodbye to the Unix model after 50 years. It would open up an entirely new world of software experimentation and craftsmanship.

Every system is driven by user adoption. At this point, it will be nearly impossible to dethrone the current methodologies. Not saying it shouldn't be done, just that it might fail.

The classic way that this has always happened in the past is by solving a specific problem in a hacky-but-cheap way as compared to existing tech. The issue I see here is I can already run Unix on a smartwatch or a car radio, so it seems difficult to understand where new computing paradigms will come from. Google's Fuchsia is a contender, but I wonder how realistic it is that it would ever become 'the standard'. Maybe the future is a world of truly heterogenous operating system design, but more likely we will employ a one-size-fits all approach just like every other industry. All car engines are about the same, all shoes are constructed with similar parts, all stoves are basically interchaneable, it is unrealistic to expect that software will be any different.

Re: I/O Is Faster Than CPU – Let’s Partition Resources and Eliminate OS Abstractions [pdf]

#79
post #69

We need entirely new OS abstractions to replace the dated notions of hierarchical file systems built around the metaphor of file cabinets, I/O as streams of bytes, terminals, process hierarchy. Essentially, say goodbye to the Unix model after 50 years. It would open up an entirely new world of software experimentation and craftsmanship.

What would you replace it with? At the very core you need two things: the notion of a unit of data and some metadata to address it. To be as flexible as possible that unit of data would probably modeled as a sequence of individually addressable bytes but it could be more structured. Such a thing is dangerous because if your structure isn't sufficiently expressive 20 years down the road people will end up imposing the…

Object systems

Re: I/O Is Faster Than CPU – Let’s Partition Resources and Eliminate OS Abstractions [pdf]

#80
post #61

We need entirely new OS abstractions to replace the dated notions of hierarchical file systems built around the metaphor of file cabinets, I/O as streams of bytes, terminals, process hierarchy. Essentially, say goodbye to the Unix model after 50 years. It would open up an entirely new world of software experimentation and craftsmanship.

Every system is driven by user adoption. At this point, it will be nearly impossible to dethrone the current methodologies. Not saying it shouldn't be done, just that it might fail.

> Every system is driven by user adoption. At this point, it will be nearly impossible to dethrone the current methodologies.

iOS, when the iPhone first came out, turned many of the entrenched perceptions about computing devices around on their head, and people embraced it.

Even without the celebrity power of someone like Apple, an experimental system could still thrive today in the shadows with a small cult of followers nurturing and developing it, until it breaks out.

Post reply on HN