Live data from Hacker News

Modern storage is plenty fast, but the APIs are bad

itnext.io

51–60 of 168 posts

Re: Modern storage is plenty fast, but the APIs are bad

#51
post #38
post #14

Earlier quoted context omitted.

The advertised bandwidth for RAM is not actually what you get per-core, which is what you care about in practice. If you want to know the upper bound on your per-core RAM bandwidth: 64 bytes (the size of a cache line) * 10 slots (in a CPU core's LFB or line fill buffer) / 100ns (the typical cost of a cache miss) * 1000000 * 1000 (to convert ns to ms to seconds) = 6400000000 bytes per second = 5.96 GiB per second RAM…

What about prefetching? Tiger Lake gets over 20 GB/s per core. https://www.anandtech.com/show/16084/intel-tiger-lake-review...

From your link

> In the DRAM region we’re actually seeing a large change in behaviour of the new microarchitecture, with vastly improved load bandwidth from a single core, increasing from 14.8GB/S to 21GB/s

Yeah, that's odd. But the article's really about cache, so maybe it's a mistake. Next para says

> More importantly, memory copies between cache lines and memory read-writes within a cache line have respectively improved from 14.8GB/s and 28GB/s to 20GB/s and 34.5GB/s.

so it looks like it's talking about cache not ram but... shrug

Re: Modern storage is plenty fast, but the APIs are bad

#52
post #43
post #42

Earlier quoted context omitted.

> The slowdown is rapid and very noticeable. That probably doesn't have anything to do with write endurance of the flash memory. When your drive's flash is mostly worn-out, you will see latency affected as the drive has to retry reads and use more complex error correction schemes to recover your data. But there are several other mechanisms by which a SSD's performance will degrade early in its lifetime depending on t…

So I can potentially recycle my used SSDs?

Almost certainly.

Assuming these are consumer SSD, the most important way to maintain good performance is to ensure that it gets some idle time. Consumer SSDs are optimized for burst performance rather than sustained performance, and almost all use SLC write caching. Depending on the drive and how full it is, the SLC cache will be somewhere between a few GB up to about a fourth of the advertised capacity. You may be filling up the cache if you write 20GB in one shot, but the drive will flush that cache in the background over the span of a minute or two at most if you don't keep it too busy.

The other good strategy to maintain SSD performance in the face of a heavy write workload is to not let the drive get full. Reserving an extra 10-15% of the drive's capacity and simply not touching it will significantly improve sustained write speeds. (Most enterprise SSD product lines have versions that already do this; a 3.2TB drive and a 3.84TB drive are usually identical hardware but configured with different amounts of spare area.)

If a drive has already been pushed into a degraded performance state, then you can either erase the whole drive or, if your OS makes proper use of TRIM commands, you can simply delete files to free up space. Then let the drive have a few minutes to clean things up behind the scenes.

Re: Modern storage is plenty fast, but the APIs are bad

#53

From the author's previous piece: https://www.scylladb.com/2020/05/05/how-io_uring-and-ebpf-wi... > Our CTO, Avi Kivity, made the case for async at the Core C++ 2019 event. The bottom line is this; in modern multicore, multi-CPU devices, the CPU itself is now basically a network, the intercommunication between all the CPUs is another network, and calls to disk I/O are effectively another. There are good reasons why n…

> in modern multicore, multi-CPU devices, the CPU itself is now basically a network, the intercommunication between all the CPUs is another network, and calls to disk I/O are effectively another. Interesting take, and NUMA CPUs have felt networked to me when I've used them, but typical multicore UMA CPUs sure haven't... is there a reason to believe this will change (or already has), or did the author mean to only tal…

Both, even multicore. Same ideas are used by Red Panda (open source kafka++ clone).

Re: Modern storage is plenty fast, but the APIs are bad

#54
One thing I have started to realize is that best case latency of an NVMe storage device is starting to overlap with areas where SpinWait could be more ideal than an async/await API. I am mostly advocating for this from a mass parallel throughput perspective, especially if batching is possible.

I have started to play around with using LMAX Disruptor for aggregating a program's disk I/O requests and executing them in batches. This is getting into levels of throughput that are incompatible with something like what the Task abstractions in .NET enable. The public API of such an approach is synchronous as a result of this design constraint.

Software should always try to work with the physical hardware capabilities. Modern SSDs are most ideally suited to arrangements where all data is contained in an append-only log with each batch written to disk representing a consistent snapshot. If you are able to batch thousands of requests into a single byte array of serialized modified nodes, you can append this onto disk so much faster than if you force the SSD to make individual writes per new/modified entity.

Re: Modern storage is plenty fast, but the APIs are bad

#55

I liked most of the piece, but some bits rubbed me the wrong way: > I was taken by surprise by the fact that although every one of my peers is certainly extremely bright, most of them carried misconceptions about how to best exploit the performance of modern storage technology leading to suboptimal designs, even if they were aware of the increasing improvements in storage technology. > In the process of writing this…

I read that as that it was what he had at hand when running the tests.

Also, if the speed and features are available as professional grade devices today, it will be available everywhere in a few years.

Re: Modern storage is plenty fast, but the APIs are bad

#56

From the author's previous piece: https://www.scylladb.com/2020/05/05/how-io_uring-and-ebpf-wi... > Our CTO, Avi Kivity, made the case for async at the Core C++ 2019 event. The bottom line is this; in modern multicore, multi-CPU devices, the CPU itself is now basically a network, the intercommunication between all the CPUs is another network, and calls to disk I/O are effectively another. There are good reasons why n…

> in modern multicore, multi-CPU devices, the CPU itself is now basically a network, the intercommunication between all the CPUs is another network, and calls to disk I/O are effectively another. Interesting take, and NUMA CPUs have felt networked to me when I've used them, but typical multicore UMA CPUs sure haven't... is there a reason to believe this will change (or already has), or did the author mean to only tal…

I guess it depends on what you consider to be "typical". If you look at a many-core chip from AMD you'll see a gradient of access latency from one core to another. You'll see the same on any Intel Skylake-X descendant, although the slope of that gradient is less. Your software will need to be very highly optimized already before you start to sweat the difference, though.

Re: Modern storage is plenty fast, but the APIs are bad

#57

I liked most of the piece, but some bits rubbed me the wrong way: > I was taken by surprise by the fact that although every one of my peers is certainly extremely bright, most of them carried misconceptions about how to best exploit the performance of modern storage technology leading to suboptimal designs, even if they were aware of the increasing improvements in storage technology. > In the process of writing this…

Yeah how many people are running apps on servers served at all or even partially by NVMe SSDs? Where I work for our on prem stuff it's basically all network storage.

Re: Modern storage is plenty fast, but the APIs are bad

#58
post #57

I liked most of the piece, but some bits rubbed me the wrong way: > I was taken by surprise by the fact that although every one of my peers is certainly extremely bright, most of them carried misconceptions about how to best exploit the performance of modern storage technology leading to suboptimal designs, even if they were aware of the increasing improvements in storage technology. > In the process of writing this…

Yeah how many people are running apps on servers served at all or even partially by NVMe SSDs? Where I work for our on prem stuff it's basically all network storage.

> network storage

Do you mean cloud storage? as in, other people's computers?

Re: Modern storage is plenty fast, but the APIs are bad

#59
post #36

I suppose _modern_ storage is fast, but how many servers are running on storage this modern? None of mine are and my work dev machine is still rocking a SATA 2.5" SSD. We're probably still a few years off from being able to switch to this fast I/O yet. With the new game consoles switching over to PCIe SSDs I expect the price of NVMe drives to drop over the next few years until they're cheap enough that the majority o…

> I expect the price of NVMe drives to drop over the next few years until they're cheap enough that the majority of computers are running NVMe drives. Price no longer has anything to do with it. PC OEMs are simply not shipping SATA SSDs any more, and major drive vendors have started to discontinue their client (OEM) SATA SSD product lines. We're just waiting for the SATA-based PC install base to be retired.

My mobo has many more SATA slots than M.2. slots. I expect there will be hybrid systems for quite a while.

Re: Modern storage is plenty fast, but the APIs are bad

#60
post #56

Earlier quoted context omitted.

> in modern multicore, multi-CPU devices, the CPU itself is now basically a network, the intercommunication between all the CPUs is another network, and calls to disk I/O are effectively another. Interesting take, and NUMA CPUs have felt networked to me when I've used them, but typical multicore UMA CPUs sure haven't... is there a reason to believe this will change (or already has), or did the author mean to only tal…

I guess it depends on what you consider to be "typical". If you look at a many-core chip from AMD you'll see a gradient of access latency from one core to another. You'll see the same on any Intel Skylake-X descendant, although the slope of that gradient is less. Your software will need to be very highly optimized already before you start to sweat the difference, though.

Here's what jeffbee is talking about: https://www.anandtech.com/show/16214/amd-zen-3-ryzen-deep-di...
Post reply on HN