远离Windows \ C ++中的虚拟内存

我正在编写一个性能至关重要的应用程序,它必须在转储到光盘之前在物理内存中存储尽可能多的数据。

我可以使用::GlobalMemoryStatusEx(...)::GetProcessMemoryInfo(...)来找出物理内存占用的百分比\ free以及当前进程处理的内存量。 使用这些数据时,我可以确保在〜90%的物理内存正在使用时转储,或者每个应用程序限制的最大值为2GB的〜90。

但是,我想要一个方法来简单地接收在系统开始使用虚拟内存之前实际剩下的字节数,特别是当应用程序将被编译为32位和64位时,而2 GB的限制不存在。

Solutions Collecting From Web of "远离Windows \ C ++中的虚拟内存"

即使您能够阻止应用程序将内存分页到磁盘,仍然会遇到VMM可能会将其他程序分页到磁盘的问题,这也可能会影响您的性能。 更不用说另一个应用程序可能会启动并占用当前占用的内存,从而导致某些应用程序内存被分页。 你打算如何处理?

有一种方法可以通过非分页池来使用不可分页的内存,但是(a)这个池比较小,(b)它被设备驱动程序使用,可能只能在内核中使用。 除非要确保系统不稳定,否则也不推荐使用它的大块。

您可能需要重新审视应用程序的设计,并试图在尝试编写自己的VMM或将Windows计算机变成基本上具有更多内存的DOS框之前将存储器分页到磁盘的可能性。

这个函数怎么样:

 int bytesLeftUntilVMUsed() { return 0; } 

几乎在所有情况下,都应该给出正确的结果;)

想象一下在256Mb的RAM上运行Windows 7(MS建议至少1GB)。 这就是你要求用户想要重新分配90%可用RAM的有效方法。

真正的问题是:为什么你需要这么多的RAM? 到底什么是“性能关键”标准?

通常,这种问题意味着你的设计有一些可怕的错误。

更新:

使用范围最高的RAM(DDR3)会给你一个12GB / s的理论传输速度,相当于每个时钟周期读取一个32位的值,并有一定的带宽余量。 我相当肯定,以这样的速度进入CPU的数据不可能做任何有用的事情 – 指令处理失速会中断这个流程。 额外的,未用的带宽可以用来将数据分页到/从硬盘上。 使用RAID时,这个传输速率可能相当高(大约是RAM带宽的1/16)。 因此,将数据传输到磁盘或从磁盘传输数据并进行处理是可行的,而不会降低性能。读取之间只需要16个周期就可以了(好吧,我的数学在这里可能有点错误)。

但是,如果你把Windows混合到一起,这一切都会发生。 你的记忆可以在任何时候消失,你的应用程序可以任意暂停,等等。 将内存锁定到内存将对整个系统产生不利的影响,从而破坏了内存定位的目的。

如果你解释你想要达到的目标和表现批评,这里有很多人会帮助你找到一个合适的解决方案,因为如果你不得不问一下系统的限制,那你确实是在做错事。

标准的解决方案是不用担心“虚拟”,担心“动态”。

虚拟内存的“虚拟”部分必须被看作是一个硬件功能,你只能通过编写自己的操作系统来打败它。

但是,对象的动态分配只是您的应用程序的设计。

静态分配您需要的对象的简单数组。 使用这些对象数组。 增加和减少那些静态分配的阵列的大小,直到你有性能问题。

哎哟。 非分页池(无法交换或分配给进程的RAM数量)通常为256 MB。 这是2GB机器上的12.5%的RAM。 如果另外90%的物理内存将被分配给一个进程,那么对所有其他应用程序,服务,内核和驱动程序来说,这个比例就会降低2.5%。 即使你只分配了85%的应用程序,仍然只剩下2.5%= 51 MB。