问题标签 [32-bit]

JVM 如何在 32 位处理器上处理 64 位的原始“long”？

在多核 32 位机器上可以并行使用多核吗？
32 位机器上的 64 位操作要慢多少？

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

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

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

我们有带 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 或预取器有关还是......什么？

感谢您的任何见解。

也在英特尔论坛上提出。

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

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

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

我有一个 C# Visual Studio 项目 (.csproj)，它引用了 Framework64 版本的System.Data. 当我尝试在另一台机器上使用MSBuild / Team Foundation Server (TFS) 进行构建时，由于 64 位 DLL 不存在而失败。

我应该绑定到框架版本，还是在 64 位机器上运行时会限制我？.NET 是否尽可能重定向绑定以使用 64 位？

我有一个我已经开发了几年的插件项目，该插件可与 [主要应用程序版本、第 3 方库版本、32 位与 64 位] 的多种组合一起使用。是否有一种（干净的）方法可以使用 autotools 创建一个构建所有版本插件的 makefile。

据我通过浏览 autotools 文档可以看出，与我想要的最接近的是拥有 N 个独立的项目副本，每个副本都有自己的 makefile。这对于测试和开发来说似乎有点不太理想，因为 (a) 我需要在所有不同的副本中不断传播代码更​​改，并且 (b) 多次复制项目会浪费很多空间。有没有更好的办法？

编辑：

一段时间以来，我一直在推出自己的解决方案，我有一个花哨的 makefile 和一些 perl 脚本来寻找各种 3rd 方库版本等。因此，我对其他非 autotools 解决方案持开放态度。对于其他构建工具，我希望它们对最终用户来说非常容易安装。这些工具还需要足够聪明，以便在没有大量麻烦的情况下搜索各种 3rd 方库和标头。我主要是在寻找一个 linux 解决方案，但一个也适用于 Windows 和/或 Mac 的解决方案将是一个奖励。

使用 ASP.NET 我需要更新一个 excel 模板。

我们的服务器在 64 位模式下运行 Windows 2008。

我正在使用以下代码访问 excel 文件：

如果应用程序池设置为启用 32 位应用程序，则代码按预期工作；但是我使用的 oracle 驱动程序失败了，因为它只有 64 位。

如果启用 32 位应用程序设置为 false，则 excel 代码将失败并出现以下错误：

未找到数据源名称且未指定默认驱动程序

有什么建议么？

我们在具有 32Gb 物理 RAM 的 64 位 Windows 2003 服务器上运行 IIS6。由于我们的 .NET 3.5 ASP.NET 应用程序中存在一些较旧的 32 位依赖项，我们目前被迫在 32 位 wow64 模式下运行我们的 IIS 工作进程，据我所知，这使我们可以访问 4Gb 的内存用于我们的工作进程。

我的问题是，如果我们使用 Web Garden 设置并配置 4 个工作进程，每个工作进程能否分别访问 4Gb 的内存，从而使我们能够访问大约 16Gb 的内存。还是我们被 ASP.NET 应用程序的 4Gb 限制所困扰？

可能更适合“机架溢出”，但从开发人员的角度来看，在 64 位 Windows 主机上将 IIS（服务于传统的经典 ASP 和 .NET）作为 32 位进程而不是 64 位进程运行的优点和缺点是什么?

与 32/32 相比，32/64（iis/服务器）的主要优势似乎是每个 IIS 进程的内存容量高达 4gb。

我期望 32/64 优于 64/64 的优势似乎是更容易访问传统的 32 位进程内 DLL（我们仍然从合作伙伴供应商那里获得一个，我们无法立即放弃），也许给定更小的内存指针，相同代码的内存占用更小。

64/64 与 32/64 相比是否有任何性能优势或其他任何可以保证现在完全切换的东西？我在这里做了任何错误的假设吗？