问题标签 [64-bit]

Knuth最近反对64 位系统，他说对于适合 4 GB 内存的程序，“它们实际上丢弃了一半的缓存”，因为指针是 32 位系统上的两倍。

我的问题是：可以通过在 64 位机器上安装 32 位操作系统来避免这个问题吗？是否有任何带宽密集型基准可以证明这种情况下的优势？

我正在尝试运行 PartCover 以在 windows x64 上使用 Gallio 测试一些测试的覆盖率。但是尝试运行它会出现以下错误。

由于以下错误，检索具有 CLSID {FB20430E-CDC9-45D7-8453-272268002E08} 的组件的 COM 类工厂失败：80040153。

编辑：我正在使用 PartCover 2.2.0

我目前有一个 32 位 dll，它是使用 Visual Studio 2003 在 C++ 中使用Managed Extensions创建的。我现在正在尝试编译 64 位版本，而无需升级到 C++/CLI。我一直在这个位置关注教程。我收到以下错误：

致命错误 C1197：无法引用 'c:\windows\microsoft.net\framework\v1.1.4322\mscorlib.dll'，因为程序已经引用了 'c:\windows\microsoft.net\framework\v2.0.50727\mscorlib。 dll'

我不知道是什么引用了 .NET 2.0 版本的 dll。

如何判断我的应用程序（在 Visual Studio 2008 中编译为Any CPU）是作为 32 位还是 64 位应用程序运行的？

我们有一个写入数据库的自定义服务（SQL 2005）。这是一个完整的 64 位环境（DB、.NET 服务）。每天早上，当我们的数据量激增时，我们的一台服务器就会崩溃。在另一台服务器上，我们运行良好。我能够注意到两台机器之间的唯一区别是遇到崩溃的那台还安装了 .NET 3.5。

有没有其他人见过这种行为？

这是今天崩溃的事件日志条目：

事件类型：错误
事件源：.NET 运行时 2.0 错误报告
事件类别：无
事件 ID：1000
日期：2008 年 11 月 6 日
时间：09 :35:03
用户：N/A
计算机：RDDARWIN02
描述：
错误应用程序 servicehost.exe ，版本 2.0.6.6，标记 48eb7b7a，故障模块 kernel32.dll，版本 5.2.3790.4062，标记 462643a7，调试？0，故障地址0x0000000000027d8d。

有关详细信息，请参阅http://go.microsoft.com/fwlink/events.asp上的帮助和支持中心 。
数据：
0000：41 00 70 00 70 00 6c 00 应用
0008：69 00 63 00 61 00 74 00 icat
0010：69 00 6f 00 6e 00 20 00 离子。
0018：46 00 61 00 69 00 6c 00 失败
0020：75 00 72 00 65 00 20 00 肯定。
0028: 20 00 73 00 65 00 72 00 .ser
0030: 76 00 69 00 63 00 65 00 副
0038: 68 00 6f 00 73 00 74 00 主机
0040: 2e 00 65 00 78 00 65 8
: 20.exe 00 32 00 2e 00 30 00 .2...0。
0050: 2e 00 36 00 2e 00 36 00 ..6...6。
0058：20 00 34 00 38 00 65 00 .4.8.e。
0060：62 00 37 00 62 00 37 00 b.7.b.7。
0068：61 00 20 00 69 00 6e 00 一个。.in
0070：20 00 6b 00 65 00 72 00 .ker
0078：6e 00 65 00 6c 00 33 00 nel3。
0080：32 00 2e 00 64 00 6c 00 2...dl
0088：6c 00 20 00 35 00 2e 00 升。.5...
0090：32 00 2e 00 33 00 37 00 2...3.7。
0098: 39 00 30 00 2e 00 34 00 9.0...4。
00a0：30 00 36 00 32 00 20 00 0.6.2。.
00a8：34 00 36 00 32 00 36 00 4.6.2.6。
00b0：34 00 33 00 61 00 37 00 4.3.a.7。
00b8：20 00 66 00 44 00 65 00 .fDe
00c0：62 00 75 00 67 00 20 00 错误。
00c8：30 00 20 00 61 00 74 00
0..at 00d0：20 00 6f 00 66 00 66
00.off 00d8：73 00 65 00 74 00 20 00 设置。
00e0：30 00 30 00 30 00 30 00 0.0.0.0。
00e8：30 00 30 00 30 00 30 00 0.0.0.0。
00f0：30 00 30 00 30 00 32 00 0.0.0.2。
00f8：37 00 64 00 38 00 64 00 7.d.8.d。
0100: 0d 00 0a 00 ....

我们有带 XP64 的 Core2 机器（戴尔 T5400）。

我们观察到，在运行 32 位进程时，memcpy 的性能在 1.2GByte/s 量级；然而，在 64 位进程中的 memcpy 可以达到大约 2.2GByte/s（或使用 Intel 编译器 CRT 的 memcpy 可以达到 2.4GByte/s）。虽然最初的反应可能只是将其解释为由于 64 位代码中可用的寄存器更广泛，但我们观察到我们自己的类似 memcpy 的 SSE 汇编代码（应该使用 128 位宽的加载存储，而不管 32 /64 位进程）展示了它实现的复制带宽的类似上限。

我的问题是，这种差异实际上是由什么引起的？32 位进程是否必须跳过一些额外的 WOW64 箍才能获得 RAM？它与 TLB 或预取器有关还是......什么？

感谢您的任何见解。

也在英特尔论坛上提出。

我有一个任意的.NET 程序集列表。

我需要以编程方式检查每个 DLL 是否是为 x86（而不是 x64 或任何 CPU）构建的。这可能吗？

我们正在开发一个 Winforms 应用程序，并正在优化启动时间。

该应用程序在 64 位 Vista 机器上运行。在我们的测试中，我们发现了一个看似反直觉的结果。在其他条件相同的情况下，目标 32 位和 64 位加载的时间减半。任何人都可以解释为什么？

谢谢。

[编辑] 我们通过 ClickOnce 部署应用程序，根据我们的研究，它在一个独特的沙箱中启动应用程序。因此它总是冷启动，因此在这里寻求提高性能是徒劳的。

我们的主要问题是项目中存在 32 位 dll。一旦我们将项目定位在 x86（即使它在 x64 上运行），加载时间就会减少一半。[/编辑]

在使用 .Net 应用程序（假设是 Asp.Net 应用程序）时，与在 32 位平台上工作相比，在 64 位平台上工作时做事的方式有什么不同。

我想的很少，因为您正在研究框架，而框架正在为您处理大部分事情，对吗？

但是，请发表您的意见。

谢谢。

Int64 和 Int32 在 32 位和 64 位 MS Windows 上的实际性能差异是什么？

在两个操作系统变体中的每一个上看到 Int64 与 Int32 的一些实际时序也很棒。XP 或 Vista 也会很有趣。

• 另请参阅有关memcpy性能的问题。