我很想知道/LARGEADDRESSAWARE切换是如何工作的，并且找不到有关实现细节的信息。
有人可以描述使用交换机时发生的事情及其后果（除了允许进程访问更多内存）吗？
答案 0 :(得分：2)
从历史上看，32位Windows系统将具有虚拟内存布局，其中应用程序仅使用低2 GB的进程'地址空间;将为内核保留高2 GB。这是记录在案的行为。改变记录的行为并不酷，除非它明确选择加入。这就是/LARGEADDRESSAWARE的用途。它在可执行标头中触发一个标志，告诉系统程序不介意使用高于2GB边界的地址。使用该标志，系统可以分配低3 GB的地址，高1 GB用于内核。
你将如何编写应用程序代码，这是一个突破性的变化是另一个问题。也许有些人会将地址转换成签名的对象并进行比较;如果地址有31位，那就会破坏。
编辑：交换机本身没有性能影响。但是，如果应用程序经常遇到超过2 GB的内存负载，则可以更积极地从缓存中获得一些性能。如果没有3GB开关，应用程序不能消耗超过2GB的虚拟内存;用开关，最多三个。
答案 1 :(得分：1)
我使用 SLAM++ ， Venice 和 100k <上的Sphere库运行了一个简单的基准测试数据集：
Dataset | Time x86 | Time x86 /LARGEADDRESSAWARE | Time x64
Venice | bad_alloc | 4276.524971 | 300.315826 sec
Sphere | 2.946498 | 3.605073 | 1.727466 sec
100k | 46.402400 | 50.196711 | 32.774384 sec
所有时间都在几秒钟内。你有它 - 性能收费可以实质性。这主要是做BLAS操作，有时使用SSE加速，整个事情都是内存限制。请注意，x86中 Venice 的峰值内存使用量略高于3.5 GB（我相信在x64系统中最高可达4 GB），在x64中，它略低于4.3 GB。其他数据集使用的内存要少得多，远低于2 GB。
对于威尼斯上的x86 /LARGEADDRESSAWARE，似乎操作系统希望在分页文件中保留大部分＆gt; 2 GB，尽管内存使用量已跳至＆gt;访问数据时为3 GB - 因此额外的成本可能源于积极的分页。此外，x64上的算术运算还有一些优势x86（程序可以使用额外的寄存器等），这可能是普通x86在小数据集上比x64慢的原因。
这是在具有2x AMD Opteron 2356 SE和16 GB 667 MHz DDR2的计算机上测量的，运行Windows Server 2003 x64。
在Windows 7上，Intel Core i7-2620M，8 GB 1333 MHz DDR3机器：
Dataset | Time x86 | Time x86 /LARGEADDRESSAWARE | Time x64
Venice | bad_alloc | 203.139716 | 115.641463 sec
Sphere | 1.714962 | 1.814261 | 0.870865 sec
100k | 18.040907 | 18.091992 | 13.660002 sec
这有相似的行为，x64比x86快，/LARGEADDRESSAWARE更慢（虽然没有前一种情况那么慢 - 它可能取决于CPU或操作系统）。
答案 2 :(得分：0)
/LARGEADDRESSAWARE没有性能影响，因为它不会影响代码生成。
不设置此标志的程序仅获取虚拟内存地址＆lt; 2 ^ 31。设置了该标志的程序可以获得虚拟地址＆gt; 2 ^ 31
这很重要，因为在程序中可能存在细微的错误，它们依赖于有符号整数数学。
E.g。指针转换为int：
void* p0 = ...; // from somewhere
void* p1 = ...; // from somewhere else
assert( p1 > p0 );
int diff = (int)p1 - (int)p0;
这将在地址存在的情况下中断＆gt; 2 GB。 因此，为了保守起见，操作系统确实会处理没有设置此标志的程序，因为它在遇到地址时可能会做一些不好的事情＆gt; 2 GB＆＃39;。
另一方面，在x86系统上，设置/3GB标志会减少内核可用的虚拟内存量，这可能会影响其性能。