进程外内存堆可在32位地址空间内工作

Question

问题：大型模拟游戏中有大量荒谬的不同对象，必须对其进行跟踪，更新并用于视觉渲染和逻辑模型更新。 仅4 GB的地址空间，您就只能在内存中容纳这么多东西。 如果诉诸磁盘，除非您很幸运并且不断访问页面高速缓存，否则事情会开始放慢速度。 但是即使那样，当文件系统同步到磁盘时，进行大量更新/写入也将是昂贵的。

假设用户至少有32GB的RAM（少数报告有64GB），并且希望进行巨大的模拟，从而导致该模型所承载的数据量比游戏中要处理的大多数事物都要多一个数量级。 它们当然具有64位操作系统（例如Windows 7 x64或Windows 8 x64）。 自然地，如果您仅将所有这些模型数据存储在进程中的虚拟地址空间中，即使使用大型地址感知，即使主机具有千兆字节和几千兆字节的可用RAM ，也会遇到内存不足的情况（因为32位进程不在虚拟地址空间 （VAS）中。

我们还要假设，出于完全无法控制的原因，您不能使主二进制文件成为64位。 您依赖于某些专有框架，花费了可笑的工时来对该框架进行编码，并且必须从第一方开始重新过渡到其他框架。 您的框架仅提供32位版本，因此您陷入了困境。

对？

也许。

我有一个随机的想法，似乎很远，因为我不知道我是否可以使它高效或实用。

如果我可以创建一个64位子进程，那么它就可以用于所有实际用途，甚至可以在非常高端的服务器机箱上使用尽可能多的RAM，而今天的任何人都可以购买并插入主板。

现在，我希望能够从模型中高效地存储和检索大数据，并将其推入子流程中，并不时地将这些数据的子部分复制到子流程中。 因此，基本上，所有容量的千兆字节（一系列非常大的树状结构和哈希表状结构）中的“主要”模型都将位于64位进程中，而32位进程将进入该进程，大量数据，对其进行处理（或者也许我应该让子进程在其中进行一些处理以将其提取下来？），然后将其删除-在32位进程中使内存使用情况易于管理。

所有模型读取/变异/模拟算法均基于以下假设：模型可在本地在进程中使用，因此像随机数组访问之类的事情很普遍。 对于我来说，很难从主要模型中提取出一些基于块的顺序读取的访问模式，而且遍历整个模型也不是很不常见。

我的目标是：

• 防止织补物因内存不足而崩溃（＃1目标）
• 性能（非常接近第二名，但是使用复杂性极高的人可能会比模拟更小，更简单的游戏的人接受更差的性能）
• 最少地重构现有代码（带有渲染调用和多线程的或多或少的香草C ++）

从一致性内存模型到必须通过孔径仔细查看比我任何时候都无法掌握的更大的模型，这似乎是一个非常艰巨的项目，这可能需要进行大量算法重新设计。

我的问题：

• 有这样做的先例吗？
• 如何在Windows上最好做到这一点？ 是否有某种共享内存，例如Linux上的共享内存，还是轻量级的超高带宽随机内存访问IPC，可以通过类似operator[]()实现将其集成到C ++中？
• 任何IPC的性能都会变得很差，甚至不值得尝试吗？ 我是否应该仅依靠磁盘（您知道数据库，键值之类的东西），然后让操作系统/文件系统找出如何使用RAM？

请记住，我需要一种极其 “闲谈”的IPC机制的支持，因为许多处理算法（AI等）都是围绕小内存访问和更新而设计的。 这在进程中足够好用，甚至对缓存局部性都有一定的关注，但是当您通过IPC访问它时，一切都变得很奇怪。

Answer 1

如果正确理解你。

如果您使用多个进程，则Windows仍将需要将页面切入和切出。

这就是我设想的尝试方式。

使用内存映射文件来映射所需磁盘上保留的内存空间的视图/部分。 您当然需要一些内部映射方案。

我现在不知道的关键是您是否可以从32位访问64位API。

Windows将神奇而有效地处理分页。 无论如何，这就是它对内存映射虚拟内存所做的工作。 我们曾经使用它来处理早期的32位NT系统上的海量数据集，而该技术才有效。

Answer 2

我的情况与您类似，GUI是32位的，但需要x64代码才能与系统接口。 我们采用的方法是使用WM_COPYDATA并在魔术过程位边界之间来回传递数据。 自然，它不如使用dll快，但这不是一种选择。 在我们的用例中，性能折衷是可以接受的。