64位整数在JVM中的效率低于32位整数吗？

Question

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

我想64位整数是解决方案。但是，如果一台运行64位JVM的机器运行涉及64位整数效率低于32位整数的效率低于？

---

顺便说一句，我使用的是信息检索包（SOLR）优化包（Drools中）和其他包装用Java编写的，而他们可能不带小数点的数据类型发挥出色（如果你认为它） 。

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将远远超过使用长，而不是一个int值的造价成本。

你也可以使用double，结果四舍五入至小数点后四位打印前/输出它。

Answer 3

一般情况下，更多的数据，你需要投四周，速度较慢是，即使在只有64位VM坚持诠释，而不是长在大多数情况下更快。

，如果你认为在内存占用方面，这变得很清楚：一百万个整数组成的阵列需要4MB，1M多头吃了8MB。

至于计算速度，有一些开销与32位指令在64位类型执行操作。但即使虚拟机可以使用64位指令（它应该在64位虚拟机上），但根据CPU的不同，它们可能仍然比32位的指令慢（加/减可能会在一个时钟内，但在64位中的乘法和除法通常比在32位中慢）。

---

一个很常见的误解是整数运算比浮点运算更快。只要你需要执行额外的操作来“规范化”你的整数，浮点数将在性能上平稳地超过你的整型实现。对于大多数应用程序来说，整数和浮点指令之间花费的时钟周期的实际差异对于大多数应用程序而言是微不足道的，因此如果您需要使用浮点数，请使用它并且不要试图自己模拟它。

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