IO faster then CPU puts CS best practice and intuition upside down.
I/O Is Faster Than CPU – Let’s Partition Resources and Eliminate OS Abstractions [pdf]
221–230 of 291 posts
Re: I/O Is Faster Than CPU – Let’s Partition Resources and Eliminate OS Abstractions [pdf]
#222In 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.…
>"If memory speed is 100ns then you would notice the memory bottleneck around the time when your processor speed is 10Mhz."
Sorry I'm not following the math there, whats the relation between 100ns and 10Mhz? Why is that the tipping point?
Re: I/O Is Faster Than CPU – Let’s Partition Resources and Eliminate OS Abstractions [pdf]
#223Earlier quoted context omitted.
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 ov…
>"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."
I think this is already happening. I think it was Aerospike that used the FTL of of NANd/NVMe drives for a direct key value store and I think another vendor maybe Fusion had an SDK for this as well. The Optane stuff looks really interesting, are there any server vendors shipping with those?
Re: I/O Is Faster Than CPU – Let’s Partition Resources and Eliminate OS Abstractions [pdf]
#224In 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.…
>"If memory speed is 100ns then you would notice the memory bottleneck around the time when your processor speed is 10Mhz." Sorry I'm not following the math there, whats the relation between 100ns and 10Mhz? Why is that the tipping point?
1 second = 1 billion nanoseconds and 1 Mhz = 1 million times a second, so if something takes 100ns you can only do it 10 millions times per second (10Mhz).
Re: I/O Is Faster Than CPU – Let’s Partition Resources and Eliminate OS Abstractions [pdf]
#225In 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.…
>"If memory speed is 100ns then you would notice the memory bottleneck around the time when your processor speed is 10Mhz." Sorry I'm not following the math there, whats the relation between 100ns and 10Mhz? Why is that the tipping point?
A 10Mhz processor has a clock cycle of 100ns (0.1 millionths of a second). Those are just rough representative numbers I picked...any particular RAM delays would be different and the actual latency would be complicated by bus speeds and protocols etc.
Re: I/O Is Faster Than CPU – Let’s Partition Resources and Eliminate OS Abstractions [pdf]
#226Earlier quoted context omitted.
You really don't remember the "web scale" memes about Mongo? It was always primarily about "performance".
I don't remember seeing that predicated as a low-level I/O savings — it was always things about being easy to cluster or avoiding the performance overheads of ACID. The pitch was usually “it's easier and you don't need a skilled DBA”.
What I heard was "You can practically scale indefinitely". Which I guess is more true of NoSQL. As is I/O savings. But it's not something I've ever heard it advertised for.
Re: I/O Is Faster Than CPU – Let’s Partition Resources and Eliminate OS Abstractions [pdf]
#227In 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.…
>"If memory speed is 100ns then you would notice the memory bottleneck around the time when your processor speed is 10Mhz." Sorry I'm not following the math there, whats the relation between 100ns and 10Mhz? Why is that the tipping point?
[deleted]
Re: I/O Is Faster Than CPU – Let’s Partition Resources and Eliminate OS Abstractions [pdf]
#228Earlier quoted context omitted.
Those are more like add-on features a driver can use if present. They don't push peripheral interfaces into a standard channel-like format. Nor are they close to one that can be exposed to application programs.
We can't expose a DMA controller directly to programs, but an API could be devised for it. Such a thing is needed even just from the mere portability point of view: making different DMA controllers on different systems look the same. Applications will typically specify transfers using virtual addresses, but DMA controllers will understand physical memory (usually, but maybe there are virtually mapped ones out there).…
> but DMA controllers will understand physical memory
Yup, this is what I’ve found on many embedded SoCs. It’s unfortunate. The fact that they need physical addresses makes them not worth using in many cases (mainly when trying to move user buffers around).
Re: I/O Is Faster Than CPU – Let’s Partition Resources and Eliminate OS Abstractions [pdf]
#229Earlier quoted context omitted.
Those are more like add-on features a driver can use if present. They don't push peripheral interfaces into a standard channel-like format. Nor are they close to one that can be exposed to application programs.
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.
Re: I/O Is Faster Than CPU – Let’s Partition Resources and Eliminate OS Abstractions [pdf]
#230Earlier quoted context omitted.
Of course, you need some agent that can communicate with the hard disk and that knows how to manage memory. Maybe its one driver, maybe its several, but these can also just be objects. Live objects, I mean. Not just blobs of data, but actors that have behaviors and are always "running." You don't even need the concept of files or filesystems. And if you do, better left to a higher level
Isn't the whole point of persistent storage like hard drives to deal with the fact that computers shut off sometimes, and nothing can be "always 'running'"? Something below the object level (possibly part of the object system, possibly a layer below that) needs to read from disk and bootstrap all those agents/live objects/actors into existence.
The storage on disk doesn't have to be a traditional hierarchical filesyste,m for anything after the kernel is loaded (+drivers), as long as the kernel is able to recombobulate the agents off the block addressable storage device, it can store them however it wants. Simply serializing swaths of memory to/from disk may not be the most efficient, but that should show its possible.