31–40 of 121 posts
Performant: still not a word.
Earlier quoted context omitted.
Seymour Cray never said "performant". Engineers say "fast" or "fast enough". Marketing types and nontechnical management seem to prefer this neologism. But it might also be a generational thing. A new coinage that I noticed in the past year that also grates on my ears: "learning" as a substitute for "lesson", as in "what were your learnings from the hackathon?" Anyone else caught this one?
Past year? Past decade champ.
Yeah per packet processing at 40Gbps and higher is problematic on regular kernels, OS stack and CPUs. A lot of really can be cache hits -- hundreds of nanoseconds. Article mentions that too: --- To put these numbers in context, acquiring a single uncontested lock on today's systems takes approximately 20ns, while a non-blocking cache invalidation can cost up to 100ns, only 25x less than an I/O operation. --- It also…
It seems like they don't make a clear distinction between latency and bandwidth. From the little I know on SSDs(don't claim to be an expert here) the sequential reads are below or on-par with high spindle speed disks.
What seems to be a better take-away would be that sequencing of your reads isn't nearly as important as it used to be. Back in games we'd duplicate data across a DVD so that we could do "seekfree" loading where duplicating 5-10MB of data would mean just a single big call to read() and gain massive load time performance.
Performant: still not a word.
Seymour Cray never said "performant". Engineers say "fast" or "fast enough". Marketing types and nontechnical management seem to prefer this neologism. But it might also be a generational thing. A new coinage that I noticed in the past year that also grates on my ears: "learning" as a substitute for "lesson", as in "what were your learnings from the hackathon?" Anyone else caught this one?
I've made that point before on YC.[1] We need to view fast storage as something other than a disk accessed through the OS, and other than slow RAM accessed as raw memory. Access through the OS is too slow, and access as raw memory is too risky. What's probably needed is something like a GPU sitting between the CPU and the fast persistent storage. Call this an SPU, or "storage processing unit." What would such a devic…
What we have is an IO offload accelerator that knows how to drive high bandwidth IOs to some external storage device. A user app doesn't interact with the device - they make shared library calls to read or write data from a particular buffer, and the accelerator (because it's cache coherent) can read / write from the virtual address space of the user space program to satisfy the request as needed. This means that the IOs bypass the entire OS driver stack, since everything is a shared library call from user space.
So yep! That exists. :-) There's other classes of accelerators out there too (and coming in the future as well). Adding additional function like compression or some form of indexing or search is stuff that we've talked about.
(edit) - https://github.com/open-power/capiflash has the code for the shared libs, the APIs, and some examples.
Performant: still not a word.
This word is one of my pet peeves as well. "Performant" is an ignorant and foolish way to say "high performance". It's like saying "voltant" instead of "high voltage". I'm all for coining new words that mean new things, but when someone says "performant" I treat it as a clue that they might be a sloppy thinker.
Performant: still not a word.
This word is one of my pet peeves as well. "Performant" is an ignorant and foolish way to say "high performance". It's like saying "voltant" instead of "high voltage". I'm all for coining new words that mean new things, but when someone says "performant" I treat it as a clue that they might be a sloppy thinker.
I've made that point before on YC.[1] We need to view fast storage as something other than a disk accessed through the OS, and other than slow RAM accessed as raw memory. Access through the OS is too slow, and access as raw memory is too risky. What's probably needed is something like a GPU sitting between the CPU and the fast persistent storage. Call this an SPU, or "storage processing unit." What would such a devic…
http://www.mellanox.com/blog/2015/04/mangstor-mellanox-show-...
This is particularly relevant to the JBOD example.
Now, there's the question of what you're actually going to do with all of that data, but in a lot of cases it's likely a durable read-mostly cache that's effectively a materialized view optimized of some (hopefully much slower write-rate) transactional store (say, product data on Amazon -- detail pages served up at some absurdly high rate, but a relatively low mutation rate).
Other workloads I can think of fall into a category I tend to think of as log processing -- a high-rate series of streaming writes which are slurped up and batch processed/reconciled to some (much smaller) state (which of course may then be exploded back out to large materialized views as above). In these scenarios, presuming the log entries have low contention over the underlying state, CPUs like those I called out above are more than up to the task of streaming over the input and optimistically updating the backing state.
Finally, in terms of real workloads, there is almost always going to be a bottleneck limiting your ability to fully utilize your resources. Either you're CPU bound and leaving network bandwidth on the table or you're network bound and are leaving CPUs/storage devices under-utilized. Massively improved storage performance local to a node is fantastic in terms of computation you can do locally, but if each network fabric upgrade costs you 10x what the previous one did to keep up with the storage/CPU available per-node, you're going to have a bad time. Amin Vahdat talked a bit about our (Google's) historical network fabric evolution: https://www.youtube.com/watch?v=FaAZAII2x0w
If I were betting on an annoying bottleneck to full resource utilization coming up in the near future, I'd put my money on network before CPU :)
Yeah per packet processing at 40Gbps and higher is problematic on regular kernels, OS stack and CPUs. A lot of really can be cache hits -- hundreds of nanoseconds. Article mentions that too: --- To put these numbers in context, acquiring a single uncontested lock on today's systems takes approximately 20ns, while a non-blocking cache invalidation can cost up to 100ns, only 25x less than an I/O operation. --- It also…
Cache miss latency was the first thing that popped into my mind as well when I saw the title. It seems like they don't make a clear distinction between latency and bandwidth. From the little I know on SSDs(don't claim to be an expert here) the sequential reads are below or on-par with high spindle speed disks. What seems to be a better take-away would be that sequencing of your reads isn't nearly as important as it u…
Not quite, but they're "only" a 2-5 times faster, not orders of magnitude faster, as with random accesses.