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

11–20 of 291 posts

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

#11

Post by pjc50 »

ajross wrote: post #9
bhouston wrote: post #2

Very interesting shift that happened over the last 2 decades. We likely haven't designed OSes or CPUs to match this new reality.

Largely because it's not really a new reality. IBM faced the same issues on the 360's half a decade (edit: sorry, century!) ago -- you could stream data off of stacked platters in a drive into core much faster than a CPU could manage the copy. And the solution was to invent "I/O Channels", which were early DMA controllers. And the VM layer (when it was added) was cognizant of this stuff, so applications could be writ…

Is there a good concise explanation of the 360 architecture available on the web? It seems historically important but I've not seen such a thing.

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

#12

Post by jandrewrogers »

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 that looks very different than the classic model you learn at university. It is always a tradeoff of burning a resource you have in abundance to optimize utilization of a resource that is scarce, and older database architectures are quite wasteful of resources that have become relatively scarce on newer hardware.

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

#13

Post by yingw787 »

There was a great blog post I read a while back about constructing a caching layer across network by Dan Luu: https://danluu.com/infinite-disk/

I asked a friend who works in a quant firm and he was like yes it’s true, and it is pretty insane.

I think there’s research Microsoft and Google are doing for RDMA over 100G Ethernet for intra data center communication as well. Pretty neat.

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

#14

Post by drfuchs »

ajross wrote: post #9
bhouston wrote: post #2

Very interesting shift that happened over the last 2 decades. We likely haven't designed OSes or CPUs to match this new reality.

Largely because it's not really a new reality. IBM faced the same issues on the 360's half a decade (edit: sorry, century!) ago -- you could stream data off of stacked platters in a drive into core much faster than a CPU could manage the copy. And the solution was to invent "I/O Channels", which were early DMA controllers. And the VM layer (when it was added) was cognizant of this stuff, so applications could be writ…

I think you mean “half a century ago”.

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

#16

Post by [deleted] »

ajross wrote: post #9
bhouston wrote: post #2

Very interesting shift that happened over the last 2 decades. We likely haven't designed OSes or CPUs to match this new reality.

Largely because it's not really a new reality. IBM faced the same issues on the 360's half a decade (edit: sorry, century!) ago -- you could stream data off of stacked platters in a drive into core much faster than a CPU could manage the copy. And the solution was to invent "I/O Channels", which were early DMA controllers. And the VM layer (when it was added) was cognizant of this stuff, so applications could be writ…

[deleted]

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

#17

Post by pjc50 »

Interesting. It's long been the case that a "computer" pretends to be a single processor to the programmer while in fact being a cloud of semi-general processors which communicate through messages. This makes that completely explicit, giving the programmer all the power and hassle involved in speaking as directly to the devices as possible while maintaining isolation. Similar esoteric architectures are already available (e.g. Tilera, or all the way back to the Inmos Transputer).

Given the allocation of particular hardware devices - NIC, RAM, NVMe - to particular processors running a (static?) application process, it's not clear how the filesystem abstraction would work or whether that's simply delegated to the application. This is very definitely a server-focused system as no mention is made of GPUs or interactive devices.

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

#18

Post by the8472 »

Don't kTLS sockets[0] with crypto offloading[1], sendfile/vmsplice, device-to-device DMA transfers[2] and possibly io_uring solve all those things on linux? Granted, they're not POSIX, but they're incremental extensions.

Netflix implemented similar extensions in freebsd[3]

[0] https://www.kernel.org/doc/Documentation/networking/tls.txt [1] https://lwn.net/Articles/734030/ [2] https://lwn.net/Articles/767281/ [3] https://people.freebsd.org/~rrs/asiabsd_2015_tls.pdf

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

#19

Post by ktpsns »

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.

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

#20

Post by [deleted] »

ktpsns wrote: 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.

[deleted]
Post reply on HN