undefined | Better HN

0 pointsnotacoward3y ago0 comments

> Basically everything these days assumes fast random disk IO

I think the point is that they shouldn't. The majority of things that people do every day should fit in memory, requiring only short bursts of sequential access when loading and when saving files. Even databases and filesystems are pretty good at avoiding or overlapping random accesses. Exceptions exist, to be sure, but if "basically everything" gets slow when it doesn't have fast random access then "basically everything minus epsilon" is broken.

0 comments

nicoburns3y 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.

ridgered43y 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.

Arrath3y 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.

notacowardOP3y 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.

j / k navigate · click thread line to collapse