[concurrency-interest] Does factoring out VarHandle-based manipulations cause performance penalties?

Dávid Karnok akarnokd at gmail.com
Wed Aug 9 07:48:30 EDT 2017


Indeed, the { } are deliberate to simulate different subclasses that build
upon AtomicReference. RxJava v1..3 use Atomic* classes (limit by Java 6 &
Android) and RxJava 4 (I'm experimenting with) will use VarHandles.

2017-08-09 13:34 GMT+02:00 Aleksey Shipilev <shade at redhat.com>:

> On 08/09/2017 01:20 PM, Dávid Karnok wrote:
> > Thanks Aleksey!
> >
> > I did a benchmark and VarHandles seem to work fine compared to
> AtomicReferences (assuming that I
> > measured the right setup):
> >
> > Benchmark                     Mode  Cnt          Score         Error
> Units
> > VarHandleCostPerf.baseline1  thrpt    5 159276715,278 ± 3571493,763
> ops/s
> > VarHandleCostPerf.bench1     thrpt    5 162339382,232 ±  763533,693
> ops/s
>
> > VarHandleCostPerf.baseline2  thrpt    5   72675096,238 ± 1262485,061
> ops/s
> > VarHandleCostPerf.bench2     thrpt    5   84963708,660 ±  596244,817
> ops/s
>
> > VarHandleCostPerf.baseline3  thrpt    5   38747819,413 ± 1513177,407
> ops/s
> > VarHandleCostPerf.bench3     thrpt    5   47328852,938 ±  157493,140
> ops/s
>
> > VarHandleCostPerf.baseline4  thrpt    5   38047055,938 ±  316562,325
> ops/s
> > VarHandleCostPerf.bench4     thrpt    5   38053864,102 ±  180163,924
> ops/s
>
> > VarHandleCostPerf.baseline5  thrpt    5   30075092,319 ±  151191,006
> ops/s
> > VarHandleCostPerf.bench5     thrpt    5   29819608,499 ± 1088452,474
> ops/s
>
> > VarHandleCostPerf.baseline6  thrpt    5   24924283,770 ±  214311,889
> ops/s
> > VarHandleCostPerf.bench6     thrpt    5   24872577,980 ±  390354,651
> ops/s
>
> > VarHandleCostPerf.baseline7  thrpt    5   21210169,977 ±  282669,696
> ops/s
> > VarHandleCostPerf.bench7     thrpt    5   21083601,549 ±  424591,111
> ops/s
>
> Pro-tip: measuring this in AverageTime with ns/op is much more readable.
>
> It seems *2 and *3 wins for VarHandles, I wonder why is that. I guess that
> is because the
> AtomicReference instances you have in the tests are actually different
> classes ("{  }" yields the
> anonymous subclass), which explains this somewhat.
>
> AtomicReferences also keep the value one dereference away, but your test
> would not show that, given
> very low cache footprint. AtomicReferenceFieldUpdater seems to be the
> better baseline, or whatever
> you use right now in Rx*?
>
> Thanks,
> -Aleksey
>
>


-- 
Best regards,
David Karnok
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20170809/3e384535/attachment-0001.html>


More information about the Concurrency-interest mailing list