Hacker News new | ask | show | jobs
by nicoburns 1303 days ago
I mean yes and no. One might make the same claim about an FPU for example. It should be possible for most software to be fast without assuming fast floating point calculations. But if it can reasonably be assumed that the deployment platform does have that capability then does it make sense to focus effort into optimising that.

I think there's an argument to be that programs should focus more on when they're reading from disk because some programs can end up slow or laggy even on SSDs. But systems not running on SSDs (outside of embedded and object storage use cases) are exceedingly rare these days. And that's only likely to be more true over time.
2 comments
ridgered4 1303 days ago
I remember adopting SSDs quite early in their lifetime despite them having controller firmware teething issues at the time. It was hands down the most significant PC upgrade I've made in the last 20 years.

That said, Windows used to run acceptably on hard drive. I don't think I could even endure Windows 10 on one now with the amount of background disk hammering it does just staring at an empty desktop.

link
Arrath 1303 days ago
I maintain that the jump from spinning rust to solid state may well be the biggest single QoL jump we'll see in consumer computing for another couple decades, barring, like, direct neural interface or something wild.
link
notacoward 1303 days ago
> systems not running on SSDs ... are exceedingly rare these days

Just because it's there doesn't mean you have to rely on it. As you yourself say:

> programs should focus more on when they're reading from disk

Yes, they should. A program's interface to storage is often one of the main limiters on its overall performance or scalability, even with the fastest kinds of storage available. In general, it's best to assume that storage access - especially random access - will be crazy slow compared to anything else. Batch it, parallelize it, overlap it with other kinds of work. Any program that is unnecessarily I/O bound, relying on storage to be fast in order to be fast itself, will be unable to take advantage of other resources (CPU, memory). That's excusable for programs whose whole purpose is to access storage - e.g. the storage servers I worked on for ~30 years including in HPC - but otherwise it's just poor design. Unfortunately, that's the norm in our industry nowadays.

link