News Bethesda releases Dishonored 2 system requirements

Games sure are getting large these days... I don't understand why they don't do a better job at compressing data. If your computer is good enough to play the game, it's good enough to handle the CPU overhead of decompressing the game's resources during loading screens. As for anything that loads during gameplay, leave that un-compressed.


In my personal experience, loading times are significantly faster when compressing data.

 

But compressing stuff slows things down, no matter how fast your PC is. If it has to do more decompression before actually working on drawing bits of the game, you will take a performance hit and loading screens (do these still exist?) will be longer.

 

Unless you have a PCIe SSD that can read way beyond SATAIII speeds, I can assure you that compressing actually improves loading speeds. Think about it: in most PCs, including those with SSDs, the main bottleneck during loading screens in games is the disk read speed. Most of the time, the CPU and/or GPU are sitting there doing very little when actual data is being read in. By compressing the data, you're effectively taking some of the load of the disk drive and dumping it on the CPU instead.

I have working proof of this, albeit outdated, but the concept remains valid. I took the game Unreal Tournament 2004 and burned it to a DVD without compression. I took the exact same data, compressed it with I think LZMA, and burned it to another disk. The non-compressed game took roughly 2 minutes to load a level, while the compressed one took about 45 seconds (and yes, I did clear the RAM buffer).

I understand that a DVD drive is incredibly slow compared to modern SSDs, but, modern CPUs are also a lot faster than the one I used for this test (which I think was a dual core). Like I said, unless you have some blazing fast $1000 SSD, it is definitely possible to improve loading speeds by compressing data.

I would also like to stress that compression for data that is loaded live (during gameplay) is a bad idea. Compressing data should be strictly for loading screens only.

 

I've monitored disk activity during loading and there is nothing at the moment that saturates a Sata 3 SSD, so all you will be doing is adding extra work for the CPU.

 

That makes a lot of misinformed assumptions. For example, let's say the game is running at 60FPS with vsync enabled and uses 4 CPU cores, none of which are maxed out. At that point, when you're loading a game level, the SSD is still the bottleneck.

Keep in mind that when an SSD is marketed to have "500MB/s read speed", that's the theoretical maximum. Just because you don't reach that speed, it doesn't mean the drive's controller isn't maxed out.

Drives get significantly slower when random reads/writes are involved (which games heavily use), but, the disk is still the bottleneck. That's why IOPs are important, because MB/s is not the only metric of drive performance and therefore is not the only way a drive can be a bottleneck. For example in the Windows 8+ task manager, you may have noticed that when looking at disk usage, you can see a drive is considered 100% in use even though it might only be reading/writing at less than 10% its total speed.

So, when you compress a game, your drive's controller will still be stuck at it's crappy 10% speed during random reads, but since there is less data to gather on the disk, it still loads faster.

 

Firstly, I'm running a NVMe 950 PRO. It is very rare to see a game go much above 100MB/s during loading times, and even if it does, it's not for more than a split second. In this scenario the CPU will have to add decompression time to the overall load time.

As for games that stream data during gameplay, the highest I've seen in GTAIV when flying low is about 120MB/s. In this scenario, decompression on the CPU would steal CPU cycles from an already CPU intensive game.

 

Any evidence to back this up? If the SSD's controller is under 100% load but the CPU threads the game uses are not under 100% use, that definitively means compression will decrease load speed. Remember, we're talking about compression here, not encryption. When you compress data, there is less data for the disk to read. If the SSD's controller is maxed out but your CPU has cycles to spare, compression will speed things up. As stated before, you are effectively taking load off of the SSD and dumping it on the CPU instead. The SSD isn't working any less hard, so that's what speeds up the loading process.

Which is why I explicitly stated that using decompression during gameplay is a bad idea.

 

That's a good point. I never would have thought of using it. For me if you were considering using the built in compression it meant you needed to do something else with the system. Either add more storage or uninstall something.

 

Yes, and I actually do do that. Unfortunately, NTFS compression is pretty bad. Sometimes you're lucky to see a 1% decrease in file size (it's meant to be fast on crappy hardware) in which case performance or load times are significantly worse. That being said, there is a certain point where if something can't be compressed enough, there definitely will never be a performance improvement. It definitely isn't something that applies to the entire game's contents, too.

 

On that note: http://www.theregister.co.uk/2016/1...microsoft_dumb_down_windows_file_compression/

 

Ultimately there is one company that successfully did do compression with their games, and that company is valve. Their game content files also known as GCF were used to compress and deduplicate files into one archive. However, this was in the early days of the steam content distribution platform. And there were people who resisted the software. It was discovered that these files could be extracted and the game could be played on compressed let me tell you now that the uncompressed version of the game performed much better than the compressed version.

 

Doom is up to 70GB, Hitman is now up to 58GB (including the recently released final episode), the list goes on and on.

Once you deduct the stuff you can't uninstall like Windows and such even a 512GB can barely hold 5 - 6 games and the publishers unleash everything on us at once rather than realizing the year has 12 month.

So unfortunately we are left with the option to resort to the troglodyte tech that is mechanical hdds.

 

Agreed. And don't forget - if you have to resort to uninstalling games you want to play again, you'll have to re-download them. 50GB+ for a single game is a lot of data you have to deal with. Even if you live in a country like South Korea with stupidly fast internet speeds, it's still going to be a substantial wait to re-download these games.

I shouldn't have to consider getting a Blu-ray drive just to affordably archive games I was playing a few months ago.

 

Everything's cyclical. Having capacity for only 5-6 games installed reminds of my first PC in the 90s where I an 8GB HDD and was uninstalling/installing games on a regular basis. Half Life, TOCA 2 and Kingpin were perennials though.

 

Yeah I thought about that, except back then it was faster to go to a store, buy the game, go back home, and install it with the discs it came with. Reinstalling games wasn't really a big deal either, since you already had the medium they came in and they didn't take that long to install. Not to mention, you didn't need to download several GB of patches back then either.

 

First, if you have a multicore CPU with one core lightly loaded or not busy, decompression is basically free, if you use a compression algorithm designed for fast decompression. The issue is not decompression time, but the need to load decompression tables into your CPU level 2 or 3 cache. This will conflict with the game. Some algorithms allow you to chose the size of tables when compressing, and you should choose a size that fits comfortably into the L1 data cache.

What if you have a dual-core CPU? (Are there any single-cores left around?) The CPU overhead of file decompression can be less than the CPU involvement in reading from disk. Of course, you expect the disk driver to use DMA (direct memory access) to avoid lots of interrupts during reading of a disk sector. But you still have at least two (and often more) interrupts per sector read. Fewer sectors is fewer interrupts, and there are two problems with interrupts. First, the interrupt handler needs to write data (to memory) to free registers for the interrupt to be processed. But the real gotcha is that the (CPU) hardware decides which core will handle the interrupt pretty much at random. So the interrupt may break a critical path in your application (game) while there is another CPU core doing nothing.

Special note for those with multiple CPU chips. On some motherboards, all interrupts go to one CPU. This speeds locality of reference and decreases cache pressure, as only that CPU serves a lot of the CPU code. Obviously, process time-outs, process switches, and page faults among other interrupts can occur on any CPU. But this can be a big help. In fact most supercomputers have local disks per CPU cluster for startup purposes, but the main disk data store is run by separate CPUs.

 

True - pros and cons, pros and cons.