1
我剛剛用Java中的循環做了一點測試。我認爲在Java中移位的速度通常比默認的整數增量更快。因此，這裏是我的示例代碼：java中循環的性能（vs vs沒有bitshift，for vs. while）
final int n = 16;
long n1 = System.nanoTime();
for (int i = 1; i < 1 << n; i <<= 1) {
// nothing
}
long n2 = System.nanoTime();
for (int i = 0; i < n; i++) {
// nothing
}
long n3 = System.nanoTime();
System.out.println("with shift = " + (n2 - n1) + " ns");
System.out.println("without shift = " + (n3 - n2) + " ns");
所以我的想法是，這N1和N2之間的時間會比N2和N3之間較小。 但是，每次運行此代碼段時，整數增量似乎都會更快。 這裏是上面代碼的輸出：
with shift = 2445 ns
without shift = 1885 ns
with shift = 2374 ns
without shift = 1886 ns
with shift = 2374 ns
without shift = 1607 ns
能有人請解釋這個beahviour？ JVM如何編譯此代碼或基於底層體系結構的答案？
Ubuntu Linux 3.5.0-17-generic i686 GNU/Linux
processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 23
model name : Pentium(R) Dual-Core CPU T4300 @ 2.10GHz
stepping : 10
microcode : 0xa07
cpu MHz : 1200.000
cache size : 1024 KB
physical id : 0
siblings : 2
core id : 0
cpu cores : 2
apicid : 0
initial apicid : 0
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 13
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx lm constant_tsc arch_perfmon pebs bts aperfmperf pni dtes64 monitor ds_cpl est tm2 ssse3 cx16 xtpr pdcm xsave lahf_lm dtherm
bogomips : 4189.42
clflush size : 64
cache_alignment : 64
address sizes : 36 bits physical, 48 bits virtual
power management:
processor : 1
vendor_id : GenuineIntel
cpu family : 6
model : 23
model name : Pentium(R) Dual-Core CPU T4300 @ 2.10GHz
stepping : 10
microcode : 0xa07
cpu MHz : 1200.000
cache size : 1024 KB
physical id : 0
siblings : 2
core id : 1
cpu cores : 2
apicid : 1
initial apicid : 1
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 13
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx lm constant_tsc arch_perfmon pebs bts aperfmperf pni dtes64 monitor ds_cpl est tm2 ssse3 cx16 xtpr pdcm xsave lahf_lm dtherm
bogomips : 4189.42
clflush size : 64
cache_alignment : 64
address sizes : 36 bits physical, 48 bits virtual
power management:
==========編輯===============
行，所以我更新了我的代碼，以獲得更好的測量。
我的JVM：
java version "1.6.0_37"
Java(TM) SE Runtime Environment (build 1.6.0_37-b06)
Java HotSpot(TM) Server VM (build 20.12-b01, mixed mode)
新代碼：
// amount of shifts
final int n = 16;
// recorded times
long n1 = 0, n2 = 0, n3 = 0, n4 = 0, n5 = 0;
// measured times
long withShiftFor = Long.MAX_VALUE;
long withoutShiftFor = Long.MAX_VALUE;
long withShiftWhile = Long.MAX_VALUE;
long withoutShiftWhile = Long.MAX_VALUE;
// instance to operate with
boolean b = true;
// do some loops to measure a better result
for (int x = 0; x < 2000000; x++) {
// for loop with shift
n1 = System.nanoTime();
for (int i = 1; i < 1 << n; i <<= 1) {
b = !b;
}
// for loop wihtout shift
n2 = System.nanoTime();
for (int i = 0; i < n; i++) {
b = !b;
}
// while loop with shift
n3 = System.nanoTime();
int i = 1;
while (i < 1 << n) {
b = !b;
i <<= 1;
}
// while loop without shift
n4 = System.nanoTime();
int j = 0;
while (j < n) {
b = !b;
j++;
}
n5 = System.nanoTime();
// take minimal time to save best result
withShiftFor = Math.min(withShiftFor, n2 - n1);
withoutShiftFor = Math.min(withoutShiftFor, n3 - n2);
withShiftWhile = Math.min(withShiftWhile, n4 - n3);
withoutShiftWhile = Math.min(withoutShiftWhile, n5 - n4);
}
System.out.println("for with shift = " + withShiftFor + " ns");
System.out.println("for without shift = " + withoutShiftFor + " ns");
System.out.println("while with shift = " + withShiftWhile + " ns");
System.out.println("while without shift = " + withoutShiftWhile + " ns");
3次運行後的新的輸出（每次運行時間超過5秒）：
for with shift = 907 ns
for without shift = 838 ns
while with shift = 907 ns
while without shift = 907 ns
for with shift = 907 ns
for without shift = 907 ns
while with shift = 907 ns
while without shift = 907 ns
for with shift = 907 ns
for without shift = 838 ns
while with shift = 907 ns
while without shift = 907 ns
所以你是正確的，幾秒鐘後有幾乎相同的結果和很多迭代。但是爲什麼for循環沒有比其他解決方案更快地移動呢？有沒有任何優化的jvm儘管增加一條線與移動提到的4條線？爲什麼增長速度與其他循環一樣快？
如果您對低級別處理器細節非常感興趣，那麼添加操作的速度往往比換檔更快。儘管移位器需要更少的硅來實現，但加法器更重要，所以它們更好的優化（並且其中更多）。也就是說，如果這個基準測試（Java）能夠揭示這種差異，我會感到驚訝。在C/C++中很難做到 - 更不用說通過JIT了。 – Mysticial
編譯代碼時，可能展開一個簡單的循環以減少分支，而移位循環可能不會。奇怪的循環條件可能不會被編譯器檢測到。 –