3 ms·
The article isn't exactly conflating RAM and flash; if it were, the conclusions would be very different. A synchronous blocking IO API is fine if you're working
by wtallis 6y ago
The article isn't exactly conflating RAM and flash; if it were, the conclusions would be very different. A synchronous blocking IO API is fine if you're working with nanosecond latencies of RAM, or with storage that's as painfully slow and serial as a mechanical hard drive.
Flash is special in that its latency is still considerably higher than that of DRAM, but its throughput can get reasonably close once you have more than a handful of SSDs in your system (or if you're willing to compare against the DRAM bandwidth of a decade-old PC). Extracting the full throughput from a flash SSD despite the higher-than-DRAM latency is what requires more suitable APIs (if you're doing random IO; sequential IO performance is easy).
- gogopuppygogo 6y agoSustainable read/write speeds are also different than peak on SSD vs RAM.
- wtallis 6y agoTrue, but that applies more to writes than reads. Most real-world workloads do a lot more reads than writes, and what writes they do perform can usually tolerate a lot of buffering in the IO stack to further reduce the overall impact of low write performance on the underlying storage.