在 64 位操作系统上运行的 32 位软件中的内存映射大文件答案

【问题标题】：Memory mapping a huge file in 32 bit software running on 64 bit OS在 64 位操作系统上运行的 32 位软件中的内存映射大文件
【发布时间】：2015-08-18 14:58:05
【问题描述】：

我在读取大文件时遇到性能问题。我想使用内存映射来解决问题。输入文件最大为 10 GB，我的程序（用 C++ 编写）是用 32 位配置构建的，目标系统是 Windows 64 位，具有 24 GB 的 RAM。这是否可以将整个大文件映射到内存？如果是，我的程序如何访问“高”地址区域（> 0xFFFFFFFF，理论上，因为我的程序是 32 位的，所以指针也是 32 位的）？

【问题讨论】：

你不编译 64 位程序有什么原因吗？
程序是很久以前写的。正在逐步升级，64位在计划中，但不是现在。
您只能以块的形式映射文件，请参阅 MSDN MapViewOfFile msdn.microsoft.com/en-us/library/windows/desktop/… 。请注意，它使用 2 个 DWORDS（高、低）作为视图开始位置的文件偏移量。尝试一次映射
为什么你认为内存映射会比常规文件 i/o 更快？这对于某些类型的访问模式可能是正确的，但在大多数情况下并非如此。
@AdrianMcCarthy：请查看stackoverflow.com/questions/32047626/… 了解有关我的问题的更多详细信息

标签： c++ memory-mapped-files memory-mapping

【解决方案1】：

你不能。 32 位程序使用不能超过 4GB 的 32 位指针，即使在 64 位操作系统上运行也是如此。

不过，有一点可能会有所帮助，那就是将您的程序与/LARGEADDRESSAWARE 选项链接起来。默认情况下，32 位 Windows 程序只能使用 2GB 的地址空间，因为某些程序假定指针的最高位始终为零，并将其用作存储附加信息的标志。如果 Windows 开始分配超过 2GB 的内存，那将会中断，因此您必须将您的程序与一个特殊选项链接，该选项告诉 Windows 您的程序不会滥用该位。这让您的程序可以使用完整的 4GB 地址空间，而不是被限制为 2GB。

【讨论】：

我猜唯一如此严重滥用top bit且意义重大以至于MSVC为他们保留top bit的程序，必须由MS人员自己编写。
第一段很好，但 /LARGEADDRESSAWARE 上的那段具有误导性且无关紧要。充其量，/LARGEADDRESSAWARE 获得一个 32 位进程 3GB 的可用地址空间，因为顶部 GB 仍然是为系统保留的，中间的一些块也是如此，所以即使使用 /LARGEADDRESSAWARE，你仍然不会有超过2GB 连续空间，这对 duong_dajgja 加载 10GB 文件没有帮助。
@AdrianMcCarthy，3GB/1GB 拆分适用于使用 /3GB 引导选项的 32 位窗口。 64 位 Windows 不需要 32 位地址空间顶部的那个千兆字节，所以large-address-aware 32-bit programs can use the full 4GB。（不过，我不知道 Windows 是否总是在地址空间的中间分配东西。）
@Wyzard：说“因为某些程序假定指针的最高位始终为零并将其用作标志来存储附加信息”是一种误导。这无关紧要，因为 3 或 4 GB 的非连续地址空间仍然无法帮助您映射 10 GB 的文件。

【解决方案2】：

在 32 位程序中，您永远无法在单个进程中一次映射整个文件，因为地址空间是 2GB 长。可以通过使用MapViewOfFile 参数在给定时刻仅映射文件的一部分。也可以使用多个进程一次映射整个文件，每个进程映射 1GB（因为单独的进程具有单独的地址空间），但这真的不切实际。

【讨论】：

如您所说，对于单个进程，地址空间是 2 GB 长，一个进程映射是否可以有 2 个不同的文件，每个文件是 1.5 GB 长？
@duong_dajgja 不，使用 2GB 地址空间，您不能映射超过 2GB。正如您所提到的，这不是内存问题，而是访问它。 2x1.5GB 不适合地址空间。如 Wyzard 的回答中所述，如果您可以获得 4GB 的地址空间，您可能会成功。