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

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

#251

Post by jnurmine » Sat, May 04, 2019, 5:41 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.

Free text? You can just as well pipe structured binary data (such as audio or images) through one or more processing elements. The processors need to understand the data, of course.

There are also other IPC mechanisms, like D-Bus.

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

#252

Post by vkaku » Sat, May 04, 2019, 5:51 AM UTC

C - (stdio) - (net) = what an ideal programming library looks like. IO ring FTW.

Eventually, you realize that you're trying to use line buffers / getc / ungetc to parse lines on that packet of data on the iio_ring to serve that cat picture for teh Internetz. :)

We need to eliminate variable length protocols to make these interfaces go away.

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

#253

Post by atq2119 » Sat, May 04, 2019, 5:53 AM UTC

thaumaturgy wrote: post #82

The paper reads like it's suggesting moving the burden of complexity in dealing with varying hardware interfaces from the kernel to userland so that userland can take direct advantage of higher performance hardware when it's available. I could see that for some very small niches, but in general I think it would be a terrible development for the industry. Hardware vendors don't like to share. They don't share code, th…

You should take a look at GPUs.

All of the complexity of 3D rendering is implemented in userspace, and that has been the case universally in production for more than 5 years now -- closer to 10, really. If you replace "all" by "almost all", you can go back much further than that, really all the way to the beginning of GPUs' existence. And yet normal application developers don't have to care, because the driver does it for them.

The point is, drivers don't have to live in kernel space, they can live in user space as well. Networking folks may start being more serious about this nowadays, but it has been the reality in GPUs for a long time.

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

#254

Post by pjmlp » Sat, May 04, 2019, 8:15 AM UTC

jstimpfle wrote: post #206

Ericson2314 wrote: post #198

Earlier quoted context omitted.

Thank you for being a breadth of wisdom in the UNIX-worshiping wilderness. You can always get mindshare being first massively underpriced thing to market.

Only that this doesn't even touch on design, or what parts could have been done better.

Sure it does, not using C to start with.

Or in another form, C should have done the same as other systems languages, do proper bounds checking, arrays and strings without implicit decay into pointers.

Second, having a proper UI story like NeXTSTEP or NeWS, and not the X11 Frankenstein.

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

#255

Post by pjmlp » Sat, May 04, 2019, 8:22 AM UTC

systemBuilder wrote: post #90

pjmlp wrote: post #72

Earlier quoted context omitted.

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…

I worked on the xerox product OS (Pilot) written by my manager, and was on the team with the designers of Multics and Swift, MIT's OSes. At MIT we all ran 4.15bsd and then 4.2bsd and UNIX was so far ahead we focused on improving it, mostly. Pilot, Multics, CTSS, were nowhere near as powerful or developer friendly as UNIX. UNIX killed off OS research for a long time!

Given what I know from XDE and Cedar, I fail to see how a text based CLI, without the graphical debuggers, REPL and GUI workflows was more developer friendly.

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

#256

Post by soup10 » Sat, May 04, 2019, 9:00 AM UTC

opportune wrote: post #241

soup10 wrote: post #238

Earlier quoted context omitted.

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.

There are tricks to pull chunks of memory into cache as is, no? Not that they are ideal.

yea its a lot of "guesswork" and trial and error trying to optimize cache usage though

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

#257

Post by cachemiss » Sat, May 04, 2019, 10:48 AM UTC

gambler wrote: post #170

jandrewrogers wrote: post #159

Earlier quoted context omitted.

How are you defining "very large"? I've used HANA and even SAP doesn't make claim of real scalability -- the practical limitations are in their own documentation. And in real scalability testing, it struggles long before you reach those limits. For sensor data, I wouldn't use it for more than a few terabytes, and even then it has a few sharp edges when it comes to performance if you are not careful. No one is going t…

I missed the part about "petabytes a day". I'm curious, which companies stores petabytes of data a day in a single database?

Generally these tend to be systems that work with machine generated data, my experience is with sensor data generated by automobiles (automated car efforts).

Naive solutions tend to either summarize the data, store as logs and then run batch processes to index in some form (or leave unindexed and just brute force the computation), or limit the incoming data rate to whatever could be indexed.

These can work for some use cases, but make it very difficult to operationalize these data sources (i.e use them to make real-timeish decisions).

Even human generated data sources (fb / twitter etc.) can generate something close to that data rate.

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

#258

Post by acdha » Sat, May 04, 2019, 11:11 AM UTC

ncmncm wrote: post #242

bunderbunder wrote: post #84

Earlier quoted context omitted.

It really is. Originally , schema normalization was just about logical consistency. But that was before query optimizers were invented, and long before they grew to be so very optimized for working with normalized schemata. Nowadays, even someone who cares 100% about performance and 0% about data integrity (And is somehow still using a relational database, yeah. So what? It's MY hypothetical.) still has good reason t…

This makes more sense than it seems to. MongoDB's insight was that the overwhelming majority of data stores don't matter enough to justify worry about correctness. It doesn't go faster than other DBs if you turn on the "do it right" flags, but their customers mostly don't. Would you be willing to wait an extra five seconds for page load to be sure the banner at the bottom of "people who looked at this also looked at…

> Would you be willing to wait an extra five seconds for page load to be sure the banner at the bottom of "people who looked at this also looked at these" list is fully up to date and correct?

This is a separate question — do you do a live query or pre-compute it? — and it’s not really significantly easier to do that with Mongo’s model.

The pitch I saw was usually based on it being easier than having to think about your data model in advance, which is relevant to your example: everyone I know who picked it did something like that, thought it was less work and that was great, and then had some problem which came down to copies of data getting out of sync and so e.g. the “also looked at” box had the wrong price or a typo which had been fixed elsewhere. Fixing that usually cancelled out what claimed performance advantages and then some.

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

#259

Post by fulafel » Sat, May 04, 2019, 11:29 AM UTC

dorlaor wrote: post #127

sytelus wrote: post #48

Earlier quoted context omitted.

There are plenty of in-memory database architectures that takes full advantage of fast random access offered by DRAMs. I think paper focuses on OS design which is still tied with assumption of slow disks.

The advantage of in-memory it's also its biggest disadvantage - it's costly. NVMe can serve almost as fast as ram and is 100x cheaper. Scylla offers single digit msec (usually 1msec) 99% latency and way more cost effective

Most databases are small though.

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

#260

Post by minipci1321 » Sat, May 04, 2019, 11:43 AM UTC

bogomipz wrote: post #220

Animats wrote: post #118

Mainframe designers had this problem under control by 1970. Mainframes had, and have, "channels". A channel is part of the processor architecture. It takes commands, sends them to a peripheral, and manages the data transfer in both directions. Channels have some privileged functions through which the OS tells them where the data is supposed to go in memory. The architecture of channels is well defined, and peripheral…

>"Mainframe designers had this problem under control by 1970. Mainframes had, and have, "channels". A channel is part of the processor architecture." What are some examples of these processors? I would be interested in reading more about these mainframe processors architecture. Might you or anyone else have some links?

You could start with http://bitsavers.informatik.uni-stuttgart.de/pdf/ibm/370/pri..., see page 185