为什么“任何 CPU(首选 32 位)"允许我在 .NET 4.5 下分配比 x86 更多的内存? [英] Why does 'Any CPU (prefer 32-bit)' allow me to allocate more memory than x86 under .NET 4.5?

查看:19
本文介绍了为什么“任何 CPU(首选 32 位)"允许我在 .NET 4.5 下分配比 x86 更多的内存?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

根据许多 SO 答案和 这篇被广泛引用的博客文章,一个为任何 CPU"构建的 .NET 4.5 应用程序,选择了首选 32 位"选项,将作为32 位和 64 位系统上的 32 位进程(与 .NET 4.0 及更早版本不同).换句话说,x86 和 AnyCPU 选择了 'prefer 32-bit' 是等效的(忽略它是否可以在 ARM 上运行).

According to many SO answers and this widely cited blog post, a .NET 4.5 application built for 'Any CPU' with the 'prefer 32-bit' option selected will run as a 32-bit process on both 32-bit and 64-bit systems (unlike in .NET 4.0 and earlier). In other words, x86 and AnyCPU with 'prefer 32-bit' selected are equivalent (ignoring whether or not it can run on ARM).

但是,我的测试表明,在 64 位系统上,AnyCPU 首选 32 位"应用程序(我确认运行 32 位)可以分配比 x86 应用程序更多的内存.我编写了一个 .NET 4.5 C# 控制台应用程序,它在循环中分配 10MB 字节数组(当然保持引用),直到它遇到 OutOfMemoryException,并在具有大量 RAM 的 64 位系统上运行它.当构建为 x86 时,它会以大约 1.2GB 的分配空间下降.构建为任何 CPU(首选 32 位)"的相同代码最多可达 1.5GB.

However, my tests have shown that on a 64-bit system an 'AnyCPU prefer 32-bit' application (which I confirm runs 32-bit) can allocate more memory than an x86 one. I wrote a .NET 4.5 C# console app that allocates 10MB byte arrays in a loop (keeping the references of course) until it hits an OutOfMemoryException, and ran it on a 64-bit system with plenty of RAM. When built as x86 it falls over at about 1.2GB allocated. The same code built as 'Any CPU (prefer 32-bit)' gets up to 1.5GB.

为什么不同?

推荐答案

事实证明,在 Visual Studio 2015 中,构建为AnyCPU(首选 32 位)"会在可执行文件上设置 IMAGE_FILE_LARGE_ADDRESS_AWARE 位(相当于运行 editbin/LARGEADDRESSAWARE 上),而它不适用于 x86 构建.这可以通过 dumpbin/HEADERS 确认并查找应用程序可以处理大 (>2GB) 地址"这一行.

It turns out that, in Visual Studio 2015, building as 'AnyCPU (prefer 32-bit)' sets the IMAGE_FILE_LARGE_ADDRESS_AWARE bit on the executable (equivalent to running editbin /LARGEADDRESSAWARE on it), whereas it does not for an x86 build. This can be confirmed with dumpbin /HEADERS and looking for the line "Application can handle large (>2GB) addresses".

Visual Studio 2013 不是这种情况.变化是 显然没有记录.

This is not the case for Visual Studio 2013. The change is apparently undocumented.

理论上,这应该给 CLR 额外的 2GB 空间.我不知道为什么可分配的内存只增加了大约 300MB.

In theory, this should give the CLR an additional 2GB to play with. I don't know why the allocatable memory only goes up by about 300MB.

这篇关于为什么“任何 CPU(首选 32 位)"允许我在 .NET 4.5 下分配比 x86 更多的内存?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆