[concurrency-interest] computeIfAbsent optimized for missing entries

Amir Hadadi amirhadadi at hotmail.com
Tue Feb 14 08:46:27 EST 2017

I went over the discussions, and found the following:

And these are the current benchmarks from caffeine (the links in the post above are dead):

> As an intermediate
> test, I measured the impact of adding a single-node prescreen
> ("1cif") before locking inside CHM.computeIfAbsent, that is similar
> to what was done in some pre-release versions:
> Same key
> cif:        1402559
> get+cif: 3775886700
> 1cif:    1760916148
> Zipf-distributed keys
> cif:     1414945003
> get+cif:  882477874
> 1cif:     618668961

You refer to 2 benchmarks in this post, ComputingTest and ComputeBenchmark. I couldn't find ComputingTest, but I found ComputeBenchmark here:

I tested only the Zipf-distributed keys, running the cif vs get + cif versions using 8 threads, OSX 10.11.6, 2.8 GHz Intel Quad Core i7.
My results were:

Result "org.sample.ComputeBenchmark.compute_spread":
  83559118.933 ±(99.9%) 18403807.660 ops/s [Average]
  (min, avg, max) = (80998142.816, 83559118.933, 86575174.221), stdev = 2848009.607
  CI (99.9%): [65155311.273, 101962926.593] (assumes normal distribution)

get + cif:
  208177607.279 ±(99.9%) 12987916.190 ops/s [Average]
  (min, avg, max) = (206351511.981, 208177607.279, 210850461.612), stdev = 2009894.407
  CI (99.9%): [195189691.090, 221165523.469] (assumes normal distribution)

So the get + cif version is faster by a factor of 2.5.
I would be very surprised to find that get + cif is slower than cif when there are no absent entries.

Do these results seem reasonable? Did you run other benchmarks that convinced you that cif is better than the alternatives?

From: Concurrency-interest <concurrency-interest-bounces at cs.oswego.edu> on behalf of Doug Lea <dl at cs.oswego.edu>
Sent: Thursday, February 9, 2017 1:51:01 PM
To: Benjamin Manes
Cc: Concurrency-interest at cs.oswego.edu
Subject: Re: [concurrency-interest] computeIfAbsent optimized for missing entries

On 02/08/2017 12:22 PM, Benjamin Manes wrote:
> In JDK9, it looks like you added a small prescreening
> <http://gee.cs.oswego.edu/cgi-bin/viewcvs.cgi/jsr166/src/main/java/util/concurrent/ConcurrentHashMap.java?r1=1.295&r2=1.296>
> to check at the first node in the bin and eagerly return. That seems
> like a smart compromise, given the performance analysis you shared on
> this forum previously that dissuaded you from adopting a full
> pre-screening.

Thanks! I forgot that this made it into jdk9 (vs jdk8).
Amir: for more details see the discussions on this in the
archives: http://cs.oswego.edu/pipermail/concurrency-interest/


Concurrency-interest mailing list
Concurrency-interest at cs.oswego.edu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20170214/081f1bd2/attachment.html>

More information about the Concurrency-interest mailing list