Being able to do better here is very impressive. I took a quick look and found two things that a paranoid benchmarker like myself would not have done: - write the benchmark in scala instead of boring java - use jdk8 instead of "head" (i.e. jdk10)
I would also have benchmarked against the intrinsified version to see how it did. On Mon, May 8, 2017 at 5:42 PM, Isaac Levy <isaac.r.l...@gmail.com> wrote: > 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 >
