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

Post by opportune » Sat, May 04, 2019, 3:32 AM UTC

soup10 wrote: post #238

deRerum wrote: post #217

In the past (like around the time most programming languages were invented) memory speeds were faster than processor speeds. So all variable accesses were instantaneous. Languages like C did not have to worry about memory hierarchies. If memory speed is 100ns then you would notice the memory bottleneck around the time when your processor speed is 10Mhz. This point was reached in the mid 1980s with the 286 processor.…

more of a hardware problem... if CPU's let you directly address and manage L1, L2, L3 cache memory high performance programmers would love it and languages like C++ would immediately add support.

Post by ncmncm » Sat, May 04, 2019, 3:42 AM UTC

asn1parse wrote: post #112

Q6T46nT668w6i3m wrote: post #92

Earlier quoted context omitted.

I enjoyed the paper. My impression is that you’d shift the burden to the runtimes that, for many applications, currently sit between POSIX and applications (e.g. see the Q&A about POSIX).

Considering the poor quality of userland software, this seems like a terrible idea.

Post by garmaine » Sat, May 04, 2019, 3:51 AM UTC

stallmanifold wrote: post #233

jandrewrogers wrote: post #12

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…

In what ways do the database architecture change when one discards the assumption that I/O is the bottleneck? Does it obviate the relational model? I always found the relational model to fit working with data sets very well since it's nice and declarative. Does that turn out to be a bottlneck assuming fast I/O?

Post by garmaine » Sat, May 04, 2019, 4:00 AM UTC

AnimalMuppet wrote: post #97

bluetomcat wrote: post #42

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.

Then... what? Do you have a positive to recommend, or just "not what we've been doing"? (It's not necessarily bad if you don't - when you're doing the wrong thing, the first step to improvement is to stop doing it.) But it seems to me that much of this can be done within the existing structure. You don't want I/O as streams of bytes? Great. Whatever new thing you think it should be, you can build that on streams of b…

Post by garmaine » Sat, May 04, 2019, 4:13 AM UTC

bluetomcat wrote: post #147

Khoth wrote: post #138

Earlier quoted context omitted.

> Why would you need to communicate with any process? Maybe I need to communicate with the currently running instance of "HTTP Server App" or "Database Engine App", not with an unrelated process my program knows nothing about. Today, I piped the output of some process I was running into grep. Neither of these programs knew about the existence of the other. Later, I used an image editor to create an image, then used a…

> Today, I piped the output of some process I was running into grep. Neither of these programs knew about the existence of the other. Only because "an unstructured stream of bytes" is the way for Unix processes to communicate. It allows for composability, but a very fragile and unsafe one, requiring programs to spit out and read free text, with all the crazy filtering and guesswork needed.