Long.bitCount micro-optimization

[Joseph D. Darcy]

Hello,

To strengthen Brian' point, running faster on at least one platform is a 
necessary but not sufficient condition for a change like this since it 
is possible the change could run slower on a different platform. To 
guard against that being the case, with data points across more 
platforms a better informed decision can be made.

Unfortunately, to my knowledge there isn't a convenient way to run a 
test like this across a large set of platforms of interest.

Cheers,

-Joe


On 5/8/2017 6:01 PM, Brian Burkhalter wrote:
> Thanks for running the numbers.
>
> On May 8, 2017, at 5:42 PM, Isaac Levy <isaac.r.levy at gmail.com 
> <mailto:isaac.r.levy at gmail.com>> wrote:
>
>> bitCountInt      avgt   10  44550.630 ± 2670.294  ns/op
>
> [41880, 47221]
>
>> bitCountIntNew   avgt   10  33904.058 ± 1108.438  ns/op
>
> [32796, 35012]
>
>> bitCountLong     avgt   10  58638.138 ± 3736.014  ns/op
>
> [54902, 62374]
>
>> bitCountLongNew  avgt   10  38700.601 ±  526.648  ns/op
>
> [38174, 39227]
>
> So the ranges don’t overlap which is important.
>
>> JDK 1.8.0_131, 2.3ghz Core i7, each run counting numbers 0 to 2^14
>
> Thing is one needs to run the benchmark on a variety of hardware. I 
> went through a lot of this sort of thing myself when evaluating among 
> other things for example the crossover thresholds for the Karatsuba 
> and Toom-Cook multiplication algorithms in BigInteger multiplication. 
> There was a lot of variation.
>
> Thanks,
>
> Brian