Author Topic: RAM FAQ  (Read 3595 times)

2017-10-19, 10:26:43

maru

  • Corona Team
  • Active Users
  • ****
  • Posts: 8665
  • Marcin
    • View Profile
(Originally created by Ryuu)

Most of the information provided in this FAQ are a gross over-simplification. Memory handling is a very complex multi-tiered system and we had to err on the side of accuracy to keep the answers as simple as we could.
General Memory Questions
Q1: What’s the difference between virtual memory and physical memory?
Physical memory are the actual DDRx sticks in your machine. Virtual memory is a virtualized view of memory provided by the OS to the applications. You can have more virtual memory than physical memory since it may not actually exist - for example when you have 32 GB RAM, operating system may tell your applications they have 64 GB available. Only when applications use some of the 64 GB, then OS will map that virtual memory into the 32 GB physical memory. The unneeded part will never be mapped.

Each application has its own virtual memory space, so that applications can’t access and change each other’s data. This is the reason why bugs in Corona/3ds Max cannot corrupt other running processes and vice versa.

Applications can only access the virtual memory. They have no direct access to the physical memory itself.

Q2: What’s the difference between memory commit size and working set?
When an application requests a memory allocation from the operating system, the system doesn’t give it a part of the physical memory right away. It instead reserves a portion of the application’s virtual memory space. Application with reserved virtual memory will get actual physical memory when it actually accesses it. Note that physical/virtual memory is allocated in 4 KB units (called pages).

Commit size is the virtual memory space that is reserved by the system as soon as an application requests memory allocation.

Working set is the actual physical memory used by the applications. This number is usually lower than the commit size since most applications allocate more memory than they actually use. The working set size can never be bigger than the actual physical memory size.


Q3: So, what exactly are the memory numbers displayed in Windows task manager?
The memory usage displayed in the task manager is usually the working set size (i.e. the actual memory used). In most Windows versions you can see extended memory statistics in the task manager, where the commit size is also displayed. See the attached screenshot for detailed description for windows 10 systems.


Q4: Why do applications slow down when system runs out of memory?
When the system runs out of physical memory, it can offload some of the least used memory from RAM to HDD (or SSD or any other storage). This lowers the working set of application(s), but the commit size stays the same - offloaded memory is still mapped to the application’s virtual address space, but when the application tries to access it, the system must first load the memory from HDD into RAM. This process is usually referred to as the “memory paging”.

Since hard-disks (even SSDs) are several orders of magnitude slower than RAM, it takes a lot of time (from the CPUs point of view) to offload or reload the memory when paging is used. This results in a severe application slowdown as well as the well-known HDD rattling sound since the HDD is usually heavily used during this process.

Maximum size of the page file on HDD (and thus maximum amount of virtual memory) can be set in the OS settings. By default Windows manages the file size itself and expands it as necessary. Except for some very specific situations when you really know what you are doing, there is no reason to manually set the page file size.


Q5: Why do applications slow down even when the task manager shows memory not being 100% used?
The reported memory usage is actually a small lie. System usually uses the free memory for data caching.

Whenever an application writes data to the hard-disk, the operating system just stores this data in RAM and then proceeds to actually write the data to the disk later so the application can immediately continue without waiting for the write to complete.

Later versions of Windows also try to detect the most used applications and preload them into memory so that they can start much faster.

All this cached data is usually not included in the task manager as used memory, but still must be accounted for when checking the memory usage for performance reasons because if an application requests additional memory, the system must first free it by writing the cached data on the hard-disk.


Q6: When does Corona emit a “low system memory” warning?
The warning is displayed whenever the system emits a “low system memory” event. We have no control over when exactly this event is emitted. It is Windows that decides that memory is running low and applications should start conserving memory.


Q7: Can’t Corona use hard-disk to offload data when there is not enough RAM?
It can and it actually does (through the system’s memory paging mechanism). Hard-disks are several orders of magnitude slower than RAM so this results in a severe application slowdown. See answer to Q4 for explanation.


Q8: Why Corona sometimes crashes on low memory and sometimes not?
When the system runs out of memory, application memory allocation requests may be denied by the OS. Application code must be specifically written to handle such situation. This often means that much more code must be written for handling such cases and usually the existing code also has to be restructured.

Older parts of Corona were originally written without giving too much thought for handling such “error” cases. Newer or rewritten code like the new displacement was written with out of memory handling in mind. When a memory allocation failure occurs, such code can roll back its changes to the scene data and just inform the user about this situation instead of crashing.

We hope that in the future most of the Corona code will be written like this, but it is not a simple task.

So the crash only occurs when the system denies memory allocations for the part of the code that is not written to handle it. If the memory runs out while in 3ds Max, it will always crash, as 3ds max does not handle low-mem situations at once.


Q9: Why is version X of Corona running fine when out of memory, but version Y slows down/crashes?
Since we are always rewriting and improving old code, different versions of Corona may have different memory access patterns. When the system is out of memory, it begins to page out the least used memory to the hard-disk (see answer to Q4 for details). Most of the slowdown is caused when the application tries to access the paged-out memory and OS has to reload it from HDD. Sometimes it just happens that the paged-out memory is accessed very rarely by the application and so there is no need to reload it. This can be for example some very large texture that is never hit during the rendering.

However many of the out-of-memory situation performance differences can be attributed to the system being in a different state (other applications running or not running) or just to the plain old placebo effect.


Q10: Why is corona running slow/showing warnings/crashing when there are still gigabytes of memory available according to task manager?
Slowdowns may be caused by the system using the free memory for caching various data. In that case the cache must first be flushed to disk before the "free" memory can be given to any application. See answer to Q5 for details.

"Low system memory" warnings are signalled by Corona when it receives a "low system memory" event from the OS. It is completely outside of our control when exactly is this event emitted. See answer to Q6 for details.

The memory usage number displayed in the task manager is the actual amount of memory used by the applications. The applications can however request that the OS reserves them a much larger amount of memory. Most applications do this and Corona is no exception. The system usually has a max limit of the memory it is willing to reserve and when this limit is reached, it will refuse memory allocation requests from the application. Unless the application has additional code to handle such cases, it will simply just crash. See answer to Q8 for details.


Q11: What happens when I run out of physical memory vs. what happens when I run out of virtual memory?
When the system runs out of physical memory, OS starts to page-out parts of the memory to the HDD which results in application slow-downs. See answer to Q4 for details.

When the system runs out of virtual memory, OS will deny any further memory applications. Applications will either handle such situation gracefully or just simply crash. In this case Windows displays a standard error message (“X stopped working” on Windows 10) making it impossible to determine if the crash was actually caused by the system running out of memory. See answer to Q8 for details.


Multiple Physical CPUs
Q12: How is physical memory used in multi-CPU systems?
Each physical CPU has its own memory controller and can have its own physical memory attached. The CPUs can access each other’s physical memory, but with a slightly higher latency than when accessing their local (directly connected) memory.


Q13: What’s the difference between SMP and NUMA memory modes?
Without going into unnecessary details, these modes just influence how the physical memory is accessed by all the CPUs in the system. This affects the system performance, but not the fact that all system CPUs always “see” all the connected RAM.


Q14: Is it better to run Corona on a system with SMP or NUMA memory mode?
Only applications specifically optimized for NUMA will benefit from that mode. Corona is not such application because it would be extremely hard if not impossible to optimize it for NUMA. Use SMP mode for best performance of Corona and most other applications.


Tl;dr: The graph in task manager is not the whole story. It shows the working set : physical memory ratio - actually used memory : physical RAM. There is also the commit size : virtual memory ratio - reserved memory : physical RAM + pagefile. Applications will slow down/crash even when enough physical memory is available in case the virtual memory runs out.