Live data from Hacker News

What every programmer should know about SSDs

databasearchitects.blogspot.com

31–40 of 163 posts

Re: What every programmer should know about SSDs

#31

The claim about parallelism isn't true. Most benchmarks and my own experience show that sequential reads are still significantly faster than random reads on most NVME drives. However, random read performance is only somewhere between a 3rd to half as fast as sequential compared to a magnetic disk where it's often 1/10th as fast.

What kind of queue depth do you test the read performance? The sequential can be made fast at low queue depth by the SSD controller doing prefetch reads internally. I've worked on such algorithms myself.

Re: What every programmer should know about SSDs

#32

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 hardw…

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…

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.

Re: What every programmer should know about SSDs

#33

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 hardw…

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…

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.

Re: What every programmer should know about SSDs

#34
A little off topic, but I bought a new Macbook Pro with the M1 chip with 8GB of RAM, and I'm worried about the swap usage of this machine wearing out the SSD too quickly. Is this an actual concern, as my swap has been in the multiple GB range with my use?

Re: What every programmer should know about SSDs

#36
post #30
post #19

What everyone should know is that flash drives can lose their data when left unpowered for as little as three months.

if that is true disks should come with a very visible note stating this... seriously, 3 months would be nothing. i doubt it is true because 3 months is a time frame which should be surpassed quite often making this more known.

Depending on manufacturer, and storage conditions, it can be up to about ten years. But the “three months” number is real: https://web.archive.org/web/20210502042514/http://www.dell.c...

Re: What every programmer should know about SSDs

#37
post #27

Earlier quoted context omitted.

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.

Re: What every programmer should know about SSDs

#38
post #34

A little off topic, but I bought a new Macbook Pro with the M1 chip with 8GB of RAM, and I'm worried about the swap usage of this machine wearing out the SSD too quickly. Is this an actual concern, as my swap has been in the multiple GB range with my use?

It's an actual concern for you. For Apple it's a variant on planned obsolescence. ;-)

Note though that memory use metrics on MacOS can been a misleading. Make sure that you're seeing what's actually there.

Re: What every programmer should know about SSDs

#39

The title should be “why SSDs mean programmers no longer have to think about hard drives”. These are all reasons SSDs are much more pleasant to work with than old platter disks.

Well, they no longer need to think about hard disks, but there are a lot assumptions from the world of hard disks that play out very differently in the SSD world.

Re: What every programmer should know about SSDs

#40
post #30
post #19

What everyone should know is that flash drives can lose their data when left unpowered for as little as three months.

if that is true disks should come with a very visible note stating this... seriously, 3 months would be nothing. i doubt it is true because 3 months is a time frame which should be surpassed quite often making this more known.

Yep, they are semivolatile limited write memory modules, not disks. Everyone should use that SV-LWMM acronym.
Post reply on HN