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

21–30 of 291 posts

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

#21

Post by aloer »

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…

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

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

#22

Post by owaislone »

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…

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

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

#24

Post by otterley »

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.

The issue being discussed in the article and amongst OS designers is that I/O throughput volumes being seen in the wild today are unable to be accepted in real time (i.e., without significant queueing delays) by otherwise unloaded CPUs.

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

#25

Post by HillaryBriss »

yingw787 wrote: post #13

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.

neat blog post! i like the table at the top comparing latencies. at one point the post says:

I'm paying $60/month for 100Mb, and if the trend of the last two decades continues, we should see another 50x increase in bandwidth per dollar over the next decade.

he seems to have more confidence in his bandwidth provider than I have in mine!

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

#26

Post by donaldihunter »

ori_b wrote: post #7
Blackstone4 wrote: post #3

Does this mean we go from virtual machines (i.e. VMWare) to kubernetes & containers in data centers? Something similar to RanchOS

It means you go from an OS that provides complex drivers to one that barely provides drivers -- essentially muxing the raw hardware between processes.

Yep, https://en.wikipedia.org/wiki/Data_Plane_Development_Kit is used for NIC offload to userspace

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

#27

Post by jchrisa »

owaislone wrote: post #22
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…

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

NoSQL is based on this realization. Rather than optimize for IO with normalization, denormalize and pipe data more or less directly from storage to clients, simplifying the compute and consistency model to make distributed data easier.

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

#28

Post by donaldihunter »

ori_b wrote: post #7
Blackstone4 wrote: post #3

Does this mean we go from virtual machines (i.e. VMWare) to kubernetes & containers in data centers? Something similar to RanchOS

It means you go from an OS that provides complex drivers to one that barely provides drivers -- essentially muxing the raw hardware between processes.

And https://superuser.openstack.org/articles/vpp-vswitchvrouter-... for userspace packet processing.

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

#29

Post by mike_ivanov »

jchrisa wrote: post #27
owaislone wrote: post #22

Earlier quoted context omitted.

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

NoSQL is based on this realization. Rather than optimize for IO with normalization, denormalize and pipe data more or less directly from storage to clients, simplifying the compute and consistency model to make distributed data easier.

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

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

#30

Post by jchrisa »

mike_ivanov wrote: post #29
jchrisa wrote: post #27

Earlier quoted context omitted.

NoSQL is based on this realization. Rather than optimize for IO with normalization, denormalize and pipe data more or less directly from storage to clients, simplifying the compute and consistency model to make distributed data easier.

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

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