I apologize for not reading much of it yet, but could someone give a quick comparison to the exokernel idea?
I/O Is Faster Than CPU – Let’s Partition Resources and Eliminate OS Abstractions [pdf]
41–50 of 291 posts
Re: I/O Is Faster Than CPU – Let’s Partition Resources and Eliminate OS Abstractions [pdf]
#42We 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.
Re: I/O Is Faster Than CPU – Let’s Partition Resources and Eliminate OS Abstractions [pdf]
#43On Exadata architecture (and the recent versions of Oracle Database) the search is made by the hardware, not the software.
I'm not a fan of Oracle, but things like that are awesome.
Re: I/O Is Faster Than CPU – Let’s Partition Resources and Eliminate OS Abstractions [pdf]
#44At 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]
#45We 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.
Amen to that. Unix was never a good design, and now is severely out of date. We can no longer afford to hack around it.
Re: I/O Is Faster Than CPU – Let’s Partition Resources and Eliminate OS Abstractions [pdf]
#46Earlier quoted context omitted.
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…
Basically this I guess: https://en.wikipedia.org/wiki/Channel_I/O
Huh that's cool, kinda of makes me wonder if the SPE[1] in Cell is somewhat of a great-grandchild of Channel I/O.
[1] https://en.wikipedia.org/wiki/Cell_%28microprocessor%29#Syne...
Re: I/O Is Faster Than CPU – Let’s Partition Resources and Eliminate OS Abstractions [pdf]
#47Earlier quoted context omitted.
Sure. But the point of (early) NoSQL was IO optimization, not logical consistency.
I was curious about the parenthetical "early" in your comment. Is this optimization no longer the case then? Could you elaborate on recent developments regarding this? I've been out of the NoSQL loop for some time and am genuinely curious.
The problem is, it varies... you have what are effectively key/value stores to document databases, column stores and everything in between. You have systems built on other systems. RethinkDB and Cockroach have different approaches than Redis, Mongo, Cassandra or others.
CockroachDB gives an SQL interface over the top of a distributed data store with better consistency and relations. Cassandra has no real relations over a BigTable/Column-Store solution. It really just depends.
I think with what's coming out of SSD/NVMe and even Optain DIMMS, that there will be databases directly tuned to control/set their own data storage in these environments.
Re: I/O Is Faster Than CPU – Let’s Partition Resources and Eliminate OS Abstractions [pdf]
#48At 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…
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.
Re: I/O Is Faster Than CPU – Let’s Partition Resources and Eliminate OS Abstractions [pdf]
#49> A prototype parakernel written in Rust is currently underdevelopment
...Where?
Re: I/O Is Faster Than CPU – Let’s Partition Resources and Eliminate OS Abstractions [pdf]
#50Sometimes our feet smell are so bad even we feel ashamed due to our feet smell
Now you can get rid from this just follow this simple method
https://zoomtips.blogspot.com/2019/04/Smelly-feet.html
Guy made world record He drive car on two wheels See his video how he is driving http://bit.ly/2ZOYaWX
See the friendship between cat and squirrel That's so cute see how much they are taking care of each others http://bit.ly/2VdHs4E