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位中慢）。

---

一個很常見的誤解是整數運算比浮點運算更快。只要你需要執行額外的操作來「規範化」你的整數，浮點數將在性能上平穩地超過你的整型實現。對於大多數應用程序來說，整數和浮點指令之間花費的時鐘週期的實際差異對於大多數應用程序而言是微不足道的，因此如果您需要使用浮點數，請使用它並且不要試圖自己模擬它。

對於實際使用哪種類型的問題：使用最適合數據表示的類型。當你到達那裏時擔心表現。看看你需要執行的操作以及你需要的精度。然後選擇提供的類型。根據你提到的圖書館來看，雙人可能會成爲贏家。