To expand a bit on Martin's point - I think your benchmark should
include a 'baseline' version of bitCountInt/bitCountLong whose
implementation simply delegates to the JDK methods
(Integer.bitCount/Long.bitCount) - I see that bitCount is on the list of
supported intrinsics [1], so, by adding th
On Mon, May 8, 2017 at 10:54 PM Martin Buchholz wrote:
>
> 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 "
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 intrinsi
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
Thanks for running the numbers.
On May 8, 2017, at 5:42 PM, Isaac Levy 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, 6
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,
On May 8, 2017, at 5:07 PM, Joseph D. Darcy 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
AMD started shipping popcnt instruction in 2007, and intel in 2008.
Does the OpenJDK runtime include a bitCount intrinsic? I can't speak
much to relevance in this regard.
But in terms of performance,
http://dalkescientific.com/writings/diary/archive/2011/11/02/faster_popcount_update.html
gives a
On 5/8/2017 1:29 PM, Doug Lea wrote:
On 05/08/2017 02:14 PM, Isaac Levy wrote:
Original message below:
The JDK impl of bitCount can be improved -- though most users will get
the hotspot intrinsic. The best source I could find for the suggestion
below is page 195: http://support.amd.com/techdocs
On 05/08/2017 02:14 PM, Isaac Levy wrote:
Original message below:
The JDK impl of bitCount can be improved -- though most users will get
the hotspot intrinsic. The best source I could find for the suggestion
below is page 195: http://support.amd.com/techdocs/25112.pdf
The int version differs
Original message below:
The JDK impl of bitCount can be improved -- though most users will get
the hotspot intrinsic. The best source I could find for the suggestion
below is page 195: http://support.amd.com/techdocs/25112.pdf
Cheers,
Isaac Levy
Proposed Long.bitCount and Integer.bitCount:
pu
Thanks for the patch. The correct forum is core-libs-dev@openjdk.java.net,
which I have CCed.
Brian
On May 7, 2017, at 5:16 PM, Isaac Levy wrote:
> Apologies if this is the wrong forum, I'm new to the OpenJDK project.
12 matches
Mail list logo
