41–50 of 121 posts
So, we are getting a lot of data, but latency is still killing. (Even more taking into account that this thing has a few stages of pipeline inside.)
Anyway, our CPU is getting distributed nearer IO and memory. We are going to get NUMA machines, everything points at it.
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 suppose you could say that someone using just about any of those words is trying to sound smart or overly formal, and so we should deny their status as words to bring the speakers down a notch.
Earlier quoted context omitted.
"This sounds interesting, but why should this be a new piece of hardware as opposed to a new OS service?" Because the entire point is that CPUs are too slow by themselves, even without the OS, let alone with it. While you were context-switching into this OS server you missed the chance to do 10 IOPs give or take an order of magnitude. Yet the OS really can't go anywhere. We can sometimes poke a hole here and sometime…
> While you were context-switching into this OS server you missed the chance to do 10 IOPs give or take an order of magnitude. I'll believe that when I see real numbers. A system call takes something like 54 ns on my laptop. With pwritev or similar, you can do quite a few IOs in a system call. (Of course, pwritev is slower than 54 ns, but that's not a fundamental constraint.) An IO requires making the IO durable if y…
[1] http://blog.tsunanet.net/2010/11/how-long-does-it-take-to-ma...
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…
[1]: http://www.tomshardware.com/charts/enterprise-hdd-charts/-02...
[2]: http://www.computerworld.com/article/2900330/apple-mac/holy-...
Earlier quoted context omitted.
eg "faster"
See also: "utilize" instead of "use."
utilise namespace std;
whilst (performant()) {
pontificate();
}
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…
This looks like the perfect job for an FPGA (with a fast enough interconnect, poster above mentions CAPI which sits on top of PCIe but I have not had a chance to try it out yet).
Since the logic inside the accelerator can do pointer chasing, it can communicate directly with the application and bypass a lot of the stuff that happens when a normal IO occurs to other FPGAs today.
Earlier quoted context omitted.
"This sounds interesting, but why should this be a new piece of hardware as opposed to a new OS service?" Because the entire point is that CPUs are too slow by themselves, even without the OS, let alone with it. While you were context-switching into this OS server you missed the chance to do 10 IOPs give or take an order of magnitude. Yet the OS really can't go anywhere. We can sometimes poke a hole here and sometime…
> While you were context-switching into this OS server you missed the chance to do 10 IOPs give or take an order of magnitude. I'll believe that when I see real numbers. A system call takes something like 54 ns on my laptop. With pwritev or similar, you can do quite a few IOs in a system call. (Of course, pwritev is slower than 54 ns, but that's not a fundamental constraint.) An IO requires making the IO durable if y…
Maybe it would be beneficial to have a coherent interface as well, considering NVMe.
Earlier quoted context omitted.
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…
SSDs are still faster than hard disks even with sequential reads. 15,000 rpm enterprise spinning disks read at about 260 MB/s [1] while NVMe SSDs (like those in a 2015 MacBook Pro) reads at >1300 MB/s [2]. [1]: http://www.tomshardware.com/charts/enterprise-hdd-charts/-02... [2]: http://www.computerworld.com/article/2900330/apple-mac/holy-...
No joke. Just got an new MBP for work. Before had a spinning disk (well hybrid). Was running some silly benchmarks that I ran before and clocked my disk throughput at about 100MB/s. On MBP got 800MB/s. I thought something broke (was hitting page cache or some trickery like that) or didn't compile things right. But no, tried other tools, looked online and it seemed correct. It really surprised me.
Earlier quoted context omitted.
Just to clarify: this is to enable programs to have more a more direct and faster interface to data, while retaining data consistency and safety that typically would be managed by the OS?! Is this not just another form of DMA (direct memory access)? And if so, how would it differ from current implementations? Sometimes DMA only refers to ram, though on many systems this is fluid between different data storage types (…
"this is to enable programs to have more a more direct and faster interface to data, while retaining data consistency and safety that typically would be managed by the OS?" No, managed by the database engine. The idea is to put the data-intensive operations of a database engine into a highly parallel SPU. The application would see an interface much like an SQL or NoSQL database.
Earlier quoted context omitted.
This looks like the perfect job for an FPGA (with a fast enough interconnect, poster above mentions CAPI which sits on top of PCIe but I have not had a chance to try it out yet).
I'm probably the poster above. ;-) Yes, we layer on top of PCIe for the physical transport, but once an adapter's in CAPI mode, it's able to do translations, participate in locks, and looks more or less like a slightly-strange other thread as far as code running on the main CPU is concerned. Since the logic inside the accelerator can do pointer chasing, it can communicate directly with the application and bypass a lo…