Does more instructions in a program use more RAM than programs with few instructions?

Started by
22 comments, last by Nicholas Kong 10 years, 1 month ago

Everytime a program runs, the entire code of the program gets loaded into main memory. So can I come into a conclusion and say that it is true a program with more instructions use more ram than programs with few instructions?

Is that why games requires a certain amount of RAM because they contain a lot of instructions and also a lot of instructions that needs to be processed by the CPU?

Advertisement

Well, yes, a program is loaded into memory so in that sense takes more RAM the larger it is in machine code form.

But the size of the executable is normally not significant in games compared to the size of loaded resources. Things like models, textures, sound files etc are orders of magnitude larger than exes. Consider how many machine instructions you could store in a kilobyte, then consider how large a texture you can store in the same amount of memory.

So exe size is not usually the reason for RAM requirements of games.


Things like models, textures, sound files etc are orders of magnitude larger than exes.

I worked with sound files in games for my 2D games. And yes those sound files do have large file size. For reasons I do not know.

Why is models and textures orders of magnitude large? Why does it used a lot of RAM?


Things like models, textures, sound files etc are orders of magnitude larger than exes.

I worked with sound files in games for my 2D games. And yes those sound files do have large file size. For reasons I do not know.

Why is models and textures orders of magnitude large? Why does it used a lot of RAM?

Well, think about a typical instruction in machine code. Varies depending on the hardware but you'll fit an entire instruction including its parameters in, say, four bytes. Four bytes is also how much it would take to store one pixel in an uncompressed RGBA texture. So a 256 x 256 texture is using the same amount of memory as 65,535 of my imaginary instructions.

65k instructions would cover a lot of program logic. A 256 x 256 texture is kind of titchy.


Everytime a program runs, the entire code of the program gets loaded into main memory. So can I come into a conclusion and say that it is true a program with more instructions use more ram than programs with few instructions?
It is not always the case that the entire program code is loaded into memory. In the cases where that is actually true, then yes more code uses more memory. This can actually become a serious problem on the older consoles (PS3/Xbox360 and similar) as well as some mobile devices, because you are often running very close to memory limits on those devices. However on PC operating systems the executable will typically be paged into active memory as needed, plus there's plenty of memory to begin with most of the time.
SlimDX | Ventspace Blog | Twitter | Diverse teams make better games. I am currently hiring capable C++ engine developers in Baltimore, MD.

Here's an example from Elder Scrolls Online.

'data' - 24.1 Gb

audio files - 5.02 Gb

video - 92.6 Mb

game.exe - 29.1 Mb

The 'data' (models, textures, quests, etc.) is over a thousand times bigger than the exe. So the exe size, in most circumstances, is insignificant in terms of memory consumption when compared to the whole.

Everytime a program runs, the entire code of the program gets loaded into main memory. So can I come into a conclusion and say that it is true a program with more instructions use more ram than programs with few instructions?


Yes. Some games/engines have problems running on constrained devices like the Wii because they can't load the executable (and needed resources) into memory (I've seen engines where just the executable by itself outstrips the Wii's meager memory constraints).

Generally, as others have said, the game's resources will swamp the size of the executable, though. Typical ballpark game EXEs are around 5-20MB while typical game assets (just the portion needed to display a particular scene/level) are generally 100s of MB, and 1,000s of MB on some of the newer titles.

The size of _one_ resource vs the executable isn't an issue. The executable may well be quite a bit larger than most resources, especially if properly compressed. A single scene is likely to require hundreds or thousands of resources loaded up at once, however, and they all add up to way more space than an executable. You only need one set of rendering/physics/game logic but you need lots of different data to feed that logic to get a game.

Sean Middleditch – Game Systems Engineer – Join my team!

Well, just do the math, a 32x32 24 bits texture only use 2208 bytes, while a 4096x4096 texture take about 50 mb, so, it scale up fast, not to mention video cutscene. Like others said, it's not the .exe that take this space, it's the amount of allocated memory to hold those assets, for example, using new and malloc in c++.

Here's an example from Elder Scrolls Online.

'data' - 24.1 Gb

audio files - 5.02 Gb

video - 92.6 Mb

game.exe - 29.1 Mb

Don't forget any DLLs shipped with the game. Those would be loaded into memory as well, and count as part of your "exe" statistics.

For a recent PC game we pushed up to about 2.5 GB of data loaded at any time. (Windows allows a 32-bit program a maximum of 3 GB address space). On certain old min-spec machines this meant some page file swapping, but for most gamers that will fit in main memory.

That 2.5 GB of data was almost entirely textures, models, and audio. The executable itself along with all the associated libraries required less than 45MB, or just under 2% of the total size.

Adding a few bytes to the executable is generally not significant for a major game title.


Is that why games requires a certain amount of RAM because they contain a lot of instructions and also a lot of instructions that needs to be processed by the CPU?

No.

You can write (and people have written) very small programs that process many terabytes of data. The size of the program does not directly correspond to the data needs.

If you want some fun examples, look back to the old PC demoscene programmers. Most were written in hand-crafted assembly while carefully watching their binary size. Many of them wrote procedural graphics. Quite a few of the later programs relied on D3D for their graphics engines. A small number of them designed systems that extended to the full amount of available memory on the system, capping out at the system's addressable limits. Re-running some of those old demoscene programs that are just a few kilobytes in size and end up processing gigabytes of graphics, well, they are just amazing. They are basically screensavers, but still amazing.

Or for a non-games industry... Some quick searching shows Walmart averages over 1 million point of sale transactions per hour, with 2.5 petabytes of financial transaction data. I doubt their point-of-sale executable is more than a few megabytes, just like game executables. The Large Hadron Collider generates 40 terabytes of sensor data per second. They do a lot of processing to handle it, but again, the executables probably aren't large. A commercial jet generates 10 terabytes of data every 30 minutes of flight time, most of it is displayed to the pilot continuously, then discarded.

It is all about the data. There is lots of it, everywhere.

This topic is closed to new replies.

Advertisement