Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

penberg.org

Post reply on HN
Print view View original

231–240 of 291 posts

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

#231

Post by stcredzero »

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…

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 peripherals are built to talk to channels. The CPU has I/O instructions to control channels in a well defined way.

I need these! Not for communication between the program and peripherals. I'd like to have these for communication between processes, threads, and software Actors. I'd like to be able to map such hardware channels to channels in Golang. What we have today are software channels implemented with, "heavy kernel mediation between the hardware and the user program," which means that one may be required to think a bit too much about how processes communicate with each other, and the performance implications and how these mechanisms can break down.

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

#232

Post by LorenPechtel »

This takes an idea I had years ago and goes much farther with it. My idea: Disk and file access is handled by the memory paging system. A 64-bit machine's segment registers can point to a space far bigger than the largest hard drives. Thus a drive ID would simply be a segment register value, the drive would be accessed by reading/writing memory at an offset from that. A file handle would likewise be a segment register value. The results of doing this would be the use of all surplus memory for disk cacheing and the paging system would take care of all disk buffering, you could efficiently read/write small chunks of data.

Now lets add their approach: When you cause a page fault from accessing stuff not in memory you get the context switch but the actual workload could be handled by an auxiliary controller, it need not be on the CPU.

Changes: Locking parts of a file would be on a friendly basis, you would be able to get around the rules. Access to remote files with small chunks of data would still be inefficient--but the vast majority of accesses are local and remote accesses are generally documents that are read in their entirety.

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

#233

Post by stallmanifold »

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?

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

#234

Post by K0SM0S »

PeterCorless wrote: post #168
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…

This checks out. A single 12 TiB RAM u-12tb1.metal on AWS EC2 goes for $30.539/hr. For a month for one (24 * 30), that's a bill of $21,988.08 USD. A single i3.16xlarge, with 15.2TB NVMe SSD goes for $4.992/hr, or $3,594.24 USD a month. 16.33% of the price. I'm not going to argue whether an in-memory database (measured in ns) wouldn't give you performance improvements over fetching data from an SSD (measured in ms). B…

At a high-level, it seems expected that since the outside world (around the DB) operates on the same tiered storage (cache > RAM > disk > backup(>n)), economically it doesn't make sense to replace any tier by its direct superior, because the bottleneck becomes the outside world (any machine/infra that's not able to keep up anyway).

Not with storage but I/O, that's what the makers of the Cell processor (PlayStation 3) had in mind originally (it was culled before the final design though): huge IO, non-stop feeding the beast. The arch-goal was to be able to link Cells together to make a "network of CPUs" (network becomes sockets link) able to parallel executions. A hard (wild?) computer science dream/problem. (the final Cell CPU has none of that iirc). I think NVLink is a decent comparison of that purpose/design.

Now running a whole infra on RAM, not just a DB, that makes more sense on paper, and I guess that's what devs do daily with e.g. test environments, like a bunch of containers over a ton of RAM. At a small enough scale, upgrading storage tier makes sense as cost becomes negligible.

For a business / at scale, short of extremely specific applications where you'd indeed have not just a DB but whatever calls it also on RAM --- and remembering that this is not economical to serve "more" users or "faster", since you'd scale horizontally for that --- the use-case or endgame of whatever this DB serves should have that speed as a hard requirement. Likely to be 'one' monster itself, like, a supercomputer? Assembling deep learning datasets from real-time feeds on-the-fly? Skynet? Big brother? :) Jokes aside, one needs a beast to feed that'll take no less to justify a 7x more expensive RAM-based anything at scale.

Normal folks, I think we'll do with caching the hell out of our data for cheap, for now at least. Until RAM becomes abundant and CPU/storage/IO extremely expensive by comparison. (was RAM ever abundant? I can't seem to remember a time when I could just buy without counting, unlike storage or FLOPS relatively to everything else).

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

#235

Post by fragmede »

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.

PalmOS had this! Applications connected to databases and read and wrote records. Sqlite acts similar for the more modern era, with a traditional hierarchical filesystem underneath the sqlite DB.

Looking at modern app-based "file" access using Google docs and its ilk are that reimagining. The UI is a list of recent files, a small number of features, and then a search box. There's not File -> Save, nor am I forced to pick using a folder metaphor, where I want to put it.

That there's (likely) an underlying hierarchical filesystem somewhere below, in the stack seems like an implementation detail. As a programmer there's a library/middleware to be used to access resources, but once inside, object based access already exists. Looking at video game save files, that's been the case for a while, with the state of objects (in fact, visible objects that the user interacts with) being saved and restored from disk.

I agree it's not as satisfying as a total paradigm shift in computing on every single level, but the notion that file system, byte stream access is a holdover from a previous era ignores practical, user facing progress we've made since.

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

#236

Post by CamperBob2 »

ncmncm wrote: post #229
CamperBob2 wrote: post #214

Earlier quoted context omitted.

They don't push peripheral interfaces into a standard channel-like format. How does this not describe a PCIe bus master? Frankly I don't understand any of this. High-performance I/O works by accessing main memory directly, just like it always has. The CPU then has to wait on main memory, just like it always has. Saying that the CPU is somehow the bottleneck seems to fall into the "not even wrong" area. There is no da…

400 Gbps is 50 GBps, or 50 bytes per ns. A 100-byte packet comes every 2ns. The bottleneck is not cache bandwidth, it is the number of instructions you have time to execute per unit of I/O: in 6 cycles you will not get to run 24 instructions, especially if you have to wait 3 cycles for your L1 cache.

But you aren't waiting on L1, except in the sense that you're waiting on line fills from main memory. If the problem is that you don't have enough time to do something with the data you're getting, how is that solvable by architectural changes external to the CPU?

In the real world, if you need to deal with 400 Gb/s, you aren't going to send it to a single general-purpose CPU using any type of bus or channel. The CPU won't see it until another ASIC (or FPGA, I suppose) crunches it first.

Yes, that may impose a limit on the speed of an external network that a CPU can deal with, but that's the way it goes. MCA was never going to save us at this end of the Moore's Law curve.

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

#238

Post by soup10 »

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.

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

#239

Post by ncmncm »

CamperBob2 wrote: post #236
ncmncm wrote: post #229

Earlier quoted context omitted.

400 Gbps is 50 GBps, or 50 bytes per ns. A 100-byte packet comes every 2ns. The bottleneck is not cache bandwidth, it is the number of instructions you have time to execute per unit of I/O: in 6 cycles you will not get to run 24 instructions, especially if you have to wait 3 cycles for your L1 cache.

But you aren't waiting on L1, except in the sense that you're waiting on line fills from main memory. If the problem is that you don't have enough time to do something with the data you're getting, how is that solvable by architectural changes external to the CPU? In the real world, if you need to deal with 400 Gb/s, you aren't going to send it to a single general-purpose CPU using any type of bus or channel. The CPU…

It is only solvable by architectural changes external to the CPU. Even at 40Gbps, which we live with now, that's 20 ns per packet, or 80 ns at a pokey 10Gbps, certainly not enough time to do a system call per packet.

So you need the hardware to divvy traffic up to multiple queues -- rings, really -- and a core for each ring. The packets just show up in memory, and the cores had just better keep up. If that looks to you like the same old POSIX architecture, I don't know what to say.

It was around 2010 that the network pipes got faster than the SAN file servers, and suddenly file output capacity had to be incorporated into network flow control.

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

#240

Post by AnIdiotOnTheNet »

thaumaturgy wrote: post #88
bluetomcat wrote: post #70

Earlier quoted context omitted.

What if we surpass file systems completely? Imagine every process having its own "non-volatile" memory area, where all persistent state is kept between restarts, with a clean OS interface to share that state to other processes? Terminals and process hierarchy are a complete no-go in a fresh design. Every entity in the system can be identified through unique IDs which can be handed down to other processes based on dif…

> Imagine every process having its own "non-volatile" memory area, where all persistent state is kept between restarts... I'll treat this seriously: as software development practices are just now beginning to mature, with more emphasis on test coverage being considered best practice, sure ... maybe. But there's still a lot of software out there for which "restart the application" (or even, "restart the stinking OS")…

Plan 9 did a pretty good job.
Post reply on HN