Long.bitCount micro-optimization

[Martin Buchholz]

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.levy at 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.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
>