https://ssd.userbenchmark.com/Compare/Samsung-980-Pro-NVMe-P...
Most developer workstations have had SSDs for many years. This applies to the Windows 10 developers, too. So they haven't paid any real attention to performance regressions on HDDs, since it still works. It's just slow. But it's a HDD so who cares?
That means there's now a lot of I/O going on before and after login, more than would have ever been tolerated in the "old days". Yes, initial boot is just streaming reads, that's easy. But once the OS gets going, it starts logging things... writing. Or finishing up the dregs of the last system update. And NAND SSDs do not handle that mix well at all. They do extremely well with all-reads and very well with all-writes, but a mix will bog them down (block granularity? I don't know why).
Optane doesn't do that. It doesn't care about reads versus writes, or small writes between larger reads. It just goes, and it responds fast no matter what the mix.
It's not really the sort of thing where you notice "wow, this is so fast". It's the sort of thing where you notice randomly sometime that "hey, I've never actually had to wait for this disk". It's harder to notice the absence of pain compared to the pain itself. With Optane, something else is always the bottleneck.
It's not a huge effect, but it was pretty easy to justify the smaller price premium for Optane a few years ago when it was introduced. I fully expected it would carve out a bigger niche for itself at the top of the performance market -- because it really is the top, ahead of anything NAND -- but that hasn't happened. More Intel failings, I guess.
So, the Windows boot speed comparison provides an indication that it'll give some benefit to personal workstations too. Whether it's worth it or not is another question entirely.
It's not an abundantly high throughput device like NVMe, but for ZIL/SLOG and other caching where it's more about volume of tiny transactions, Optane is very useful.
Of course in enterprise you'd just buy a PCIe card with the characteristics your workloads require which makes Optane very "prosumer", so I understand why Intel would axe the line.
On my Gentoo Linux, there are absolutely no writes during booting.
On the other hand, for my job, I have installed Windows 10 Enterprise on several kinds of embedded computers.
Some of those computers used some ancient model of Transcend SATA SSDs, which had an extremely low writing speed, of only around 40 Mbyte/s, much like a memory card (and not like a good one).
After the default installation of Windows 10, the booting was unbelievably slow, it could take maybe a half hour or so. When Windows 10 decided that it must install updates, it was much worse. The computer became available after booting only after a few hours.
I had to waste a few days with the unhelpful Windows Knowledge Base and with some more helpful Internet forums, until I discovered how to shut down all the Windows services that wanted to write to the SSD during booting, so that eventually the booting time of Windows reached an acceptable value of less than a minute.
On the same hardware Linux booted almost instantly, because the SSD reading speed was decent, unlike its writing speed.
There are Linux distributions that I do not use, e.g. Ubuntu, and I would not be surprised if those also come with default configurations that attempt to write during booting, e.g. for updating file indexing databases, or other such crap.
Optane SSDs have extremely low latency, which is critical for sequential operations.
Most operating systems have long phases of largely single-threaded synchronous I/O, or nearly so. They certainly can't maintain queue depth required to even approach 500K IOPS.
IOPS do not tell the whole story here. Consider disk A, at 1M IOPS, against disk B, at 1k IOPS. Suppose the workload is light, at only 500 IOPS, which are "small" enough to service quickly. Which disk is higher performing?
You might say they're both capable of the task, so just get the cheaper one. This is wrong. Assume, for sake of a simple argument, that disk A can respond in 1us to these requests, and disk B in 1ms. That is, they'd be able to hit "max IOPS" on these requests, if only you have enough. Then disk A services the whole thing in 500us per second, or 0.05% used, and disk B in 500ms per second, or 50% used.
So disk A is in fact actually 1000x faster, if you're waiting on its result. Which, for single-threaded operations, you often are. If you're instead optimizing for throughput, you don't care.
Either point of view can be correct, at different times or for different systems. Ignorance that both points of view exist is how things like bufferbloat are everywhere now.
It's not an "other reason". IO operations at queue depth 1 are a direct measurement of latency. Queue depth 1 is not about throughput at all.
> Suppose the workload is light, at only 500 IOPS, which are "small" enough to service quickly.
I will assume the workload is light in CPU too, since spending half the time waiting for the disk is apparently not an instant disqualification.
> So disk A is in fact actually 1000x faster, if you're waiting on its result. Which, for single-threaded operations, you often are. If you're instead optimizing for throughput, you don't care.
If you're waiting on a bunch of results and disk A gets them to you significantly faster, it sounds like your initial premise of "only 500 IOPS" was wrong or misleading.
If you have a response time you want to meet, then you should measure IOPS with a sliding window of that many milliseconds. If it's still 500 at most, then disk B will still be fine for meeting your target.
If it turns out that "500" actually comes in bursts of 50 operations, and you want to be done in 10 milliseconds, then you should label your workload as "5k IOPS". Put in a drive that does at least 10k and you'll see all calculations done in under a frame; basically perfect latency. A drive a million times faster would have no practical difference.
Latency is a much bigger factor with conventional filesystem APIs. If you had fully async filesystem APIs that read offset x1 on file f1, offset x1 on file2, offset x100 on file f100 all at the same time then you would see linear scaling and the difference between Optane and NAND would grow smaller. However, that would require learning a new and much harder paradigm (you now have to be aware of parallelism inside SSDs). Optane is a simple upgrade that requires no software changes.
BTW, I don't think they ever made much difference in gaming. My understanding is that they were optimized for database like workloads, where you get lots of small disparate writes.