在 64 位 java 中使用 longs 而不是 ints 会受益吗答案

【问题标题】：Will using longs instead of ints benefit in 64bit java在 64 位 java 中使用 longs 而不是 ints 会受益吗
【发布时间】：2011-08-04 14:09:31
【问题描述】：

在 64 位 VM 中，使用 longs 而不是 ints 在性能方面会做得更好，因为 long 在 java 中是 64 位，因此提取和处理 64在 64 位系统中，位字可能比拉 32 位字更快。（我期待很多 NO，但我正在寻找详细的解释）。

编辑：我的意思是“在 64 位系统中拉取和处理 64 位字可能比拉取 32 位字更快”，因为我假设在 64 位系统中拉出 32位数据将要求您首先获取 64 位字，然后屏蔽前 32 位。

【问题讨论】：

在某些处理器上，将 32 位字读入 64 位寄存器比读取 64 位字要慢。但大多数（全部？）现代处理器都没有这个问题。

标签： java performance io 64-bit

【解决方案1】：

将long 用于int 通常可能会减慢您的速度。

您最关心的是 64 位 CPU 上的 int 是否需要额外的处理时间。这在现代流水线 CPU 上是极不可能的。我们可以用一个小程序轻松测试。它所操作的数据应该足够小以适合 L1 缓存，因此我们正在测试这个特定的问题。在我的机器上（64bit Intel Core2 Quad）基本没有区别。

在实际应用中，大多数数据不能驻留在 CPU 缓存中。我们必须担心将数据从主内存加载到缓存，这相对非常慢并且通常是瓶颈。此类加载以 64 字节或更多的“缓存行”为单位进行，因此加载单个 long 或 int 将花费相同的时间。

但是，使用long 会浪费宝贵的缓存空间，因此缓存未命中会增加，这是非常昂贵的。 Java 的堆空间也很紧张，所以 GC 活动会增加。

我们可以通过读取具有相同数量元素的巨大long[] 和int[] 数组来证明这一点。它们比缓存可以包含的要大得多。长版本在我的机器上花费的时间增加了 65%。测试受限于memory->cache的吞吐量，long[]内存量大了100%。（为什么不多花 100% 的时间超出了我的理解；显然其他因素也在起作用）

【讨论】：

另一方面，在多处理器上的多线程应用程序中，如果您在同一个 8 字节机器字中有两个 4 字节变量并且它们经常被不同的线程/处理器访问'通常会看到显着放缓（大约 10 倍或更差）与将它们放在单独的机器字中。（当然，如果它们在同一个缓存行中，即使是单独的机器字也不是很好。）
@irreputable，为什么使用 long 而不是 int 会浪费缓存空间？
我的意思是如果你用long代表int，显然会占用更多空间。
对迭代器变量使用 long 会导致错误的代码（不是展开的循环，可能更糟糕的分支预测等）

【解决方案2】：

我总是根据您的问题域使用正确的数据类型。

我的意思是，如果您需要 64 位长，则使用 64 位长，但如果您不需要 64 位长，则使用 int。

在 64 位平台上使用 32 位并不昂贵，根据性能进行比较是没有意义的。

对我来说这看起来不对：

for(long l = 0; l<100; l++)
 //SendToTheMoon(l);

和SendToTheMoon无关。

【讨论】：

你的答案对于企业应用程序来说已经足够了，但是可以说我正在尝试对我的程序进行微优化，该程序没有 GUI 并且以性能为导向。不会拉一百万次 32 位数据一百万次，甚至比拉 64 位数据慢一微秒。我真的想在这里找到答案，而不是引起争论。:)
@Suraj Chandran - 我不知道在里面放一些计时代码并测试看看你是否能获得 .0000001 更好的性能，可能性很小。
但是你在理论上怎么说，你有什么反对我的理论的问题，或者你的事情是错的？如果不是至少理论上它应该更慢。最后，为什么在这种情况下实际在理论上会有所不同
@Suraj Chandran - 我的回答是“原样”，我不相信您会看到根据您的问题或您的 cmets 改变的性能。我可能是错的，因此测试它。我总是通过使用你需要的东西来生活，在这种情况下，如果我可以通过使用 int / short 来获得，我到底为什么要使用 long？
虽然这是个好建议，但它并不能回答所提出的问题

【解决方案3】：

可能更快，也可能更慢。取决于特定的 Java 实现，以及您如何使用这些变量。但总的来说，这可能不足以担心差异。

【讨论】：

为什么要依赖实现？ “你如何使用这些变量”是什么意思？
有些实现内部有 64 位堆栈，有些有 32 位堆栈。变量大小会影响变量对齐方式，其中，变量对齐会影响多任务处理的执行方式。方程中有很多不同的变量。
你能告诉我至少一个 64 位实现，它有一个 32 位堆栈。难以置信:)
实际上，很难相信即使是 32 位实现也有 32 位堆栈，但那是另一回事。但我知道几个早期的“64 位”实现有一个 32 位堆栈。不知道还有没有。
更直接地回答您的问题：我很确定第一个 Sun“64 位”JVM 具有 32 位堆栈。这是一个通过重新编译他们的 32 位 JVM 和一些 64 位调整以利用 64 位寻址特性而构建的组合。同样，IBM 生产了两个具有 32 位堆栈的“64 位”JVM。不过，第一个“生产”64 位 JVM 可能是 IBM iSeries JVM，它确实从一开始就拥有 64 位堆栈，因为它是从头开始构建为 64 位 JVM（而Sun 和其他 IBM JVM 产品线是从 32 位 JVM 和#ifdefed 扩展而来的。