![[H]ard|Forum](/styles/hardforum/xenforo/logo_dark.png){kind=logo}
Considering how the other way around game tend to be (often very few files with some big unique files of 30 gig with everything in a single well compressed format) for the specific subject, it could be quite a different subject.
CPU bottleneck is common and SATA is already quite fast for good compression ratio compressed data:
Full disclosure: I'm not an expert, however how I understand it... Its the filesystem and software. SSDs shine at high queue depths, where you have 30+ load/store instructions penned into a schedule, but when the software isn't really asking for that and instead asking for a handfull of files, checking them, noting down logs for how everything went, then checking to see if everything is ready for them, then checking to see what it needs next: its just sluggish and slow, and queue depths can't get long enough to really make the NVM-E SSD excel.
Microfiles.
But games tend to be only a small numbers of extremely well optimized giant files,latest Uncharted games has 40 gig and a 24 gig .psarc files for the textures, a 4.4 gig file for the sounds, 2.3 for the english voices so on.
I wasn't talking about games.
Yes I was making a counter point of not being sure for that to be the case has NVMe does not seem much faster in scenario without any micro files and those application that use micro files will often have a cpu work by files ratio so big for it to not matter much (and for those files to fit in ram).
Multiple things. Often it's CPU setup and processing time swamping out transfer time. Very frequently, the I/O is random, not sequential; worse, the random I/O is often issued sequentially, so queue depths are very small. NVMe drives aren't all that much better than SATA drives at handling a steady drip of random I/O requests.
That's no help unless the game reads a big chunk of the file and caches it. More typically, there will be some sort of index and the game will only read the texture piece or sound/speech fragment that it needs. As far as the SSD is concerned, that's still small random transfers.
Which one would assume optimized game engine do, some game like a COD still made to run on regular PS4 HDD I would imagine try to be in sequential read mode quite a bit
Caches it where? You mentioned 24 and 40 gigabyte files, that's not going to work with a typical 16GB RAM desktop. Even caching an entire 4+ gig phrase file might be an issue, given everything else that a game engine might want/need to keep in memory. Caching stuff you won't need is a waste of time and space, and without clairvoyance, it's pretty hard to predict what will be needed in general; even if it were known, it's not always possible to arrange that data needed sequentially by some particular gameplay runtime are stored sequentially in the file. It's going to depend on the player path through the game. I'm sure there are occasions where it's likely that if you got chunk A, you'll need B and C as well. It's unlikely that those occasions comprise enough data to make sequential read speed differentials among SSD's apparent to the user.
In ram, say an expected to be used 14 gig of stuff that goes into ram and VRAM a lot of it can be optimised to be continuous sequential read.
Coincidentaly, I came across this article: https://benhoyt.com/writings/io-is-no-longer-the-bottleneck/ It's somewhat technical, intended for programmers, but in summary: You can read data from an SSD faster than the CPU can process it, even when it's a fairly simple task.
That's going to be a problem when there's 16 GB of ram in the computer, and you still need lots of room for game engine code, framebuffers, game logic data, etc etc. VRAM adds another 8 GB or so, but a lot of that is needed for GPU processing, and it's no help when you are dealing with sounds or voice that doesn't go out the video port. We're still pretty far from the point at which game engine designers can assume 32 or 64 GB of RAM.
Direct-to-GPU will probably make some difference and work to the NVMe advantage, yes. There's still going to be a fair amount of randomness given that you can't predict the player's path through the game, so it's impossible to always store data sequentially in the file in the same order as the game will demand it. Which implies that you'll end up with random reads no matter how much you try to optimize it.
