I like that it compiles to a single instruction, but lots of languages already have this; it's pretty common.
Even boring old Java has had Integer.bitCount for many years.
Even boring old Java has had Integer.bitCount for many years.
I think the point is that Rust makes it much easier to use that opcode instruction. It's possible but hard with GCC using __builtin_popcount(), but, I'd guess totally impossible in Java due to lack of a JVM instruction for the same.
If you look at the openjdk9 sources you will notice that it is annotated as intrinsic candidate[0]. But earlier versions also have intrinsics for that[1], it's just not annotated as such.
[0] http://hg.openjdk.java.net/jdk9/jdk9/jdk/file/23721aa1d87f/s... [1] https://gist.github.com/apangin/7a9b7062a4bd0cd41fcc#file-ho...
I don't understand why you would guess at what Java can do when you can find out for certain?
public class Test {
private static int bitCount(int a) {
return Integer.bitCount(a);
}
public static void main(String[] args) {
while (true) {
bitCount(14);
}
}
}
Compiles bitCount to 0x000000011e637980: sub rsp,0x18
0x000000011e637987: mov QWORD PTR [rsp+0x10],rbp ;*synchronization entry
; - Test::bitCount@-1 (line 4)
0x000000011e63798c: popcnt eax,esi ;*invokestatic bitCount
; - Test::bitCount@1 (line 4)
0x000000011e637990: add rsp,0x10
0x000000011e637994: pop rbp
0x000000011e637995: test DWORD PTR [rip+0xfffffffff10ed665],eax # 0x000000010f725000
; {poll_return}
0x000000011e63799b: ret
There's your popcnt instruction. No need to guess.