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.burkhal...@oracle.com> wrote: > > On May 8, 2017, at 5:07 PM, Joseph D. Darcy <joe.da...@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
