[
https://issues.apache.org/jira/browse/CASSANDRA-15213?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17014686#comment-17014686
]
Benedict Elliott Smith commented on CASSANDRA-15213:
----------------------------------------------------
Interesting. I get:
{code}
addAndGet
# Run progress: 0.00% complete, ETA 00:00:13
# Fork: 1 of 1
# Warmup Iteration 1: 39047588.027 ops/s
# Warmup Iteration 2: 42432555.911 ops/s
# Warmup Iteration 3: 42290231.202 ops/s
Iteration 1: 42252484.876 ops/s
Iteration 2: 41715818.895 ops/s
Iteration 3: 40307394.422 ops/s
Iteration 4: 40383945.073 ops/s
Iteration 5: 38825162.703 ops/s
Result
"org.apache.cassandra.test.microbench.LatencyTrackingBench.benchInsertToDEHR":
40696961.194 ±(99.9%) 5170160.207 ops/s [Average]
{code}
{code}
compareAndSet
# Run progress: 0.00% complete, ETA 00:00:13
# Fork: 1 of 1
# Warmup Iteration 1: 18926088.938 ops/s
# Warmup Iteration 2: 19504293.182 ops/s
# Warmup Iteration 3: 19261074.598 ops/s
Iteration 1: 19399456.839 ops/s
Iteration 2: 18979470.788 ops/s
Iteration 3: 18720138.076 ops/s
Iteration 4: 18458839.475 ops/s
Iteration 5: 18776539.883 ops/s
Result
"org.apache.cassandra.test.microbench.LatencyTrackingBench.benchInsertToDEHR":
18866889.012 ±(99.9%) 1351167.820 ops/s [Average]
{code}
i.e. twice the throughput with {{addAndGet}}. There is no material difference
to my version:
{code}
public void updateBucket(AtomicLongArray buckets, int index, long value)
{
index = stripedIndex(index, (int) Thread.currentThread().getId() &
(nStripes - 1));
buckets.addAndGet(index, value);
}
{code}
It's possible it's an issue of JDK? Perhaps yours is not replacing
{{addAndGet}} with the relevant {{lock xadd}} assembly? This seems pretty
unlikely, I think this has happened for a long time, but you could try looking
at the assembly that's produced.
> DecayingEstimatedHistogramReservoir Inefficiencies
> --------------------------------------------------
>
> Key: CASSANDRA-15213
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15213
> Project: Cassandra
> Issue Type: Bug
> Components: Observability/Metrics
> Reporter: Benedict Elliott Smith
> Assignee: Jordan West
> Priority: Normal
> Fix For: 4.0-beta
>
>
> * {{LongAdder}} introduced to trunk consumes 9MiB of heap without user
> schemas, and this will grow significantly under contention and user schemas
> with many tables. This is because {{LongAdder}} is a very heavy class
> designed for single contended values.
> ** This can likely be improved significantly, without significant loss of
> performance in the contended case, by simply increasing the size of our
> primitive backing array and providing multiple buckets, with each thread
> picking a bucket to increment, or simply multiple backing arrays. Probably a
> better way still to do this would be to introduce some competition detection
> to the update, much like {{LongAdder}} utilises, that increases the number of
> backing arrays under competition.
> ** To save memory this approach could partition the space into chunks that
> are likely to be updated together, so that we do not need to duplicate the
> entire array under competition.
> * Similarly, binary search is costly and a measurable cost as a share of the
> new networking work (without filtering it was > 10% of the CPU used overall).
> We can compute an approximation floor(log2 n / log2 1.2) extremely cheaply,
> to save the random memory access costs.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
