Long.bitCount micro-optimization

[Isaac Levy]

jmh:run -t1 -f 1 -wi 5 -i 10 BitCountTest

bitCountInt      avgt   10  44550.630 ± 2670.294  ns/op
bitCountIntNew   avgt   10  33904.058 ± 1108.438  ns/op

bitCountLong     avgt   10  58638.138 ± 3736.014  ns/op
bitCountLongNew  avgt   10  38700.601 ±  526.648  ns/op

JDK 1.8.0_131, 2.3ghz Core i7, each run counting numbers 0 to 2^14

https://gist.github.com/isaacl/338a3f88e7d18a0c64bf9aed6e4a816b

Isaac


On Mon, May 8, 2017 at 8:11 PM, Brian Burkhalter
<brian.burkhalter at oracle.com> wrote:
>
> On May 8, 2017, at 5:07 PM, Joseph D. Darcy <joe.darcy at oracle.com> wrote:
>
>> This is a case of "jmh results or it isn't faster." [1]
>>
>> It is challenging to evaluate such changes as being universally faster without benchmark results, especially for small methods like this. Without compelling performance support, my preference would be to leave the current Java implementation as-is, especially when there are VM intrinsics on many platforms.
>
> I concur.
>
> Brian