JVM中64位整数的效率是否低于32位整数？

Question

背景：我想存储精确到4位小数的数字，而不是舍入。所以我想在内部使用整数;例如，12.3456在内部表示为123456。但是对于32b整数，我可以计算仅高达214748 ，这非常小。

我猜64位整数是解决方案。但是，如果运行64位JVM的计算机，那么涉及64位整数效率低于的操作是否比32位整数高呢？

---

BTW，我正在使用信息检索包（Solr），优化包（Drools）和其他用Java编写的 包，它们可能不适合使用decimal数据类型（如果你建议的话） ）。

Answer 1

即使速度较慢，我也怀疑这会是你系统的瓶颈。您很可能会在程序的其他部分出现更严重的性能问题。

此外，this question的答案提供了更多细节，但基本上是“它依赖于平台”。 64位不会比32位慢。

Answer 2

这很可能取决于平台。我见过使用long代替int的情况大约快10％。用于Java 5.0的64位JVM比用于Java 5.0的32位JVM慢约5％-10％。 Java 6似乎没有这个问题。

我认为除以10000的成本远远超过使用long而不是int值的成本。

您也可以使用double，在打印/输出结果之前将结果四舍五入到小数点后四位。

Answer 3

通常情况下，需要投入的数据越多，速度就越慢，因此即使在64位虚拟机上坚持使用int而不是long也会在大多数情况下更快。

如果从内存占用方面考虑，这一点就变得非常清楚了：一百万个整数的阵列需要4MB，1M长就需要8MB。

至于计算速度，使用32位指令对64位类型执行操作会有一些开销。但即使VM可以使用64位指令（它应该在64位VM上），取决于CPU，它们仍然可能比它们的32位速率慢（加/减可能会在一个时钟内，但是64位的乘法和除法通常比32位慢。

---

一个非常常见的误解是整数数学比浮点数学更快。一旦你需要执行额外的操作来“规范化”整数，浮点数就会在性能上超过你的整数实现。对于大多数应用程序，在整数和浮点指令之间花费的时钟周期的实际差异是可以忽略的，因此如果您需要浮点数，请使用它并且不要尝试自己模拟它。

对于实际使用哪种类型的问题：使用最适合数据表示的类型。当你到达那里时担心性能。查看您需要执行的操作以及所需的精度。然后选择提供该类型的类型。从您提到的图书馆来看，双倍可能会成为赢家。