5 ms·

Is there any reason it needs to be a contiguous block of memory?

• gfodor 9y ago
  For one thing, modern game engines often have custom allocators and a large array of performance critical bits of code that assume cache locality. So in general, having the memory involved be non-contigous could break lots of assumptions.
• DiThi 9y ago
  It's much simpler and much faster to make a chunk of code completely isolated in user space by masking the addresses it reads/writes to. For example, masking with 0xFFFF is the same as doing modulo 16. Add another bit to the mask and you're doing modulo 32, and so on. That's why I think the block must be not only contiguous, but also aligned. I may be wrong about the alignment now that I think about it. But the contiguous part is clear.
• Const-me 9y ago
  Legacy code and development time. When I write C++ code that deals with large datasets, I try to avoid large continuous buffers as much as possible. For cache locality, an aligned 1GB buffer is practically the same as a set of 64 aligned continuous buffers, 16MB/each. You’ll only hit RAM latency when crossing the boundary between the buffers, i.e. only 63 times through the whole 1GB of data. One problem is std::vector. The standard says the whole vector must be continuous, i.e. to split large buffer into smaller chunks, one needs to implement a custom container on top of that. Apparently, authors of C++ think the problem will go away by itself, with the switch to 64-bit platforms.
  • DiThi 9y ago
    The problem does go away because of how addressing works. If you read my other comment, the address is masked for fast and safe sandboxing. If you have a huge virtual address space, it's practically guaranteed you'll have a contiguous chunk even when the actual memory is very fragmented.