我最近對 Integer.bitCount 做了一些調(diào)查。我發(fā)現(xiàn)一個有趣的結(jié)果是 Integer.bitCount 比我自己的 func 快得多，甚至代碼都是一樣的。我以為是 JIT 的原因，但我查了文檔，發(fā)現(xiàn) JIT 是基于運行時策略的。這讓我很困惑。public static void main(String[] args) { long sum = 0; long start, end; start = System.currentTimeMillis(); for (int i = Integer.MIN_VALUE; i != Integer.MAX_VALUE; i++) { sum += bitCount(i); //sum += Integer.bitCount(i); } end = System.currentTimeMillis(); System.out.println(sum); System.out.println(end - start);}private static int bitCount(int i) { i = i - ((i >>> 1) & 0x55555555); i = (i & 0x33333333) + ((i >>> 2) & 0x33333333); i = (i + (i >>> 4)) & 0x0f0f0f0f; i = i + (i >>> 8); i = i + (i >>> 16); return i & 0x3f;}// 對于 bitCount 結(jié)果687194767368715// 對于 Integer.bitCount 結(jié)果687194767361892
1 回答
慕田峪9158850
TA貢獻(xiàn)1794條經(jīng)驗 獲得超7個贊
您的基準(zhǔn)不準(zhǔn)確。但不管這一點，一個原因是因為Integer#bitCount被標(biāo)記為@HotSpotIntrinsicCandidate。這意味著 HotSpot JVM 可以用匯編代碼替換方法體來提高性能。從注釋的源代碼：
@HotSpotIntrinsicCandidate注釋特定于 HotSpot 虛擬機(jī)。它表明帶注釋的方法可能（但不保證）被 HotSpot VM 內(nèi)在化。如果 HotSpot VM 將帶注釋的方法替換為手寫程序集和/或手寫編譯器 IR（編譯器固有的）以提高性能，則方法被內(nèi)在化。注釋是 Java 庫內(nèi)部的@HotSpotIntrinsicCandidate，因此不應(yīng)該與應(yīng)用程序代碼有任何關(guān)聯(lián)。
嘗試禁用內(nèi)在函數(shù)并再次運行測試；您應(yīng)該會看到顯著放緩。
添加回答
舉報
0/150
提交
取消