Comment by andrewmcwatters | Hacker News Reader

Comment by andrewmcwatters | Hacker News Reader

Parent Full thread

andrewmcwatters

My opinion is probably... not technically correct... until you have to deal with drive reliability and write guarantees, but I don't think programmers actually have to know anything about SSDs in the same way that developers had to know particular things about HDDs.

This is out of pure speculation, but there had to be a period of time during the mass transition to SSDs that engineers said, OK, how do we get the hardware to be compatible with software that is, for the most part, expecting that hard disk drives are being used, and just behave like really fast HDDs.

So, there's almost certainly some non-zero amount of code out there in the wild that is or was doing some very specific write optimized routine that one day was just performing 10 to 100 times faster, and maybe just because of the nature of software is still out there today doing that same routine.

I don't know what that would look like, but my guess would be that it would have something to do with average sized write caches, and those caches look entirely different today or something.

And today, there's probably some SSD specific code doing something out there now, too.

Games used to spend a lot time optimizing CD/DVD layout. Because reading from that is REALLY slow. Optimize mostly meant keep data contiguous. But sometimes it meant duplicate data to avoid seeks.

The canonical case is minimize time to load a level. Keep that level’s assets contiguous. And maybe duplicate data that is shared across levels. It’s a trade off between disc space and load time.

I’m not familiar with major tricks for improving after a disc is installed to drive. (PS4 games always streamed data from HDD, not disc.)

Even consoles use different HDD manufacturers. So it’d be pretty difficult to safely optimize for that. I’m sure a few games do. But it’s rare enough I’ve never heard of it.

While reading through the Quake 3 source code, I noticed that whenever the FS functions were reading from a CD, they were doing so in a loop, because the fread/fopen functions instead of hanging and waiting for the CD to spin up sometimes just returned an error. It wasn't just slow, it was also hilarious at times.

This reminds me of Valve’s GCF (grid cache file, officially, or game cache file, commonly). The benefits must have purely occurred on consoles for the reasons you outlined, because cracked Valve games that had GCF files extracted ran faster than the official retail releases on PCs!

Stream loading is another technique that's used to reduce load time. You start loading data for the next level as the player approaches a boundry and you let them enter the next level before all of the assets(ussally textures) have finished loading.

Consoles also do this with HDDs. That's been one of the talking points around the PS5 from the beginning, with Sony saying that games would get more storage space efficient because they don't need redundancy for faster loading anymore.

This is very very true. The PS5 does hardware decompression, so games by default are now going to be compressed. For a real world reference of how big a difference that makes, see fortnite turning on compression [0] (disclaimer: I worked for epic on fortnite at the time)

[0] https://www.ign.com/articles/fortnites-latest-patch-makes-it...

I had not loaded ign without blockers in years. That was painful.

Hah, sorry. Ive always found their articles to have the least fluff on the topic, despite the awful awful website.

> The PS5 does hardware decompression, so games by default are now going to be compressed.

If that really is cause and effect, that's a bit disappointing. For any game that isn't assuming you have an ultra-fast SSD, normal CPU decompression can handle things quite well. Such a hard nudge shouldn't have been necessary.

With few exceptions, video games have been keeping their assets on disk in compressed form for a long time. It's a major embarrassment when someone ships a game with uncompressed audio, and impractical to ship with uncompressed image, texture or video assets (though these can be shipped in compressed form with unnecessarily high resolution).

The hardware decompression acceleration in new consoles doesn't exactly make it easier to use compression for the game assets. Rather, it makes it practical to load compressed assets on-demand instead of reading and decompressing into RAM during the loading screen.

> With few exceptions, video games have been keeping their assets on disk in compressed form for a long time.

Well, we can point to fortnite up there, but also a very large fraction of the games I have on steam can be shrunk by a third just by applying filesystem-level compression, despite it using weak algorithms and small blocks. I'm sure there's compression involved, but it's not even meeting a minimum bar of competency.

You can optimize for less/shorter drive seeks on rotational media by reordering requests: https://en.wikipedia.org/wiki/Elevator_algorithm

Right, the average programmer probably should, or already is, depending on some existing abstraction to optimizes writes based on storage medium.

Reply on news.ycombinator.com