commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Thomas <ma...@apache.org>
Subject Re: [Pool] Performance Tests for Pool-277
Date Wed, 24 Sep 2014 07:20:01 GMT
On 24/09/2014 00:51, Bernd Eckenfels wrote:
> Hello Mark,
> 
> I did some micro benchmarks on the max-only thing. And they somewhat
> look like I have expected on my 4core/8threads:
> 
> 1 thread
> Benchmark                               Mode  Samples         Score  Score error  Units
> n.e.j.t.MyBenchmark.atomicMax          thrpt        5  71754699,465  4916943,615  ops/s
> n.e.j.t.MyBenchmark.synchronizedMax    thrpt        5  31398785,726  1071751,697  ops/s
> 
> 2 threads 
> Benchmark                               Mode  Samples          Score  Score error  Units
> n.e.j.t.MyBenchmark.atomicMax          thrpt        5  111773939,071  6478325,697  ops/s
> n.e.j.t.MyBenchmark.synchronizedMax    thrpt        5    8197066,038   457199,732  ops/s
> 
> 4 threads
> Benchmark                               Mode  Samples          Score   Score error  Units
> n.e.j.t.MyBenchmark.atomicMax          thrpt        5  190326272,383  11287614,702  ops/s
> n.e.j.t.MyBenchmark.synchronizedMax    thrpt        5    5227629,001     35488,823  ops/s
> 
> 6 threads
> Benchmark                               Mode  Samples          Score   Score error  Units
> n.e.j.t.MyBenchmark.atomicMax          thrpt        5  257831969,334  21506920,317  ops/s
> n.e.j.t.MyBenchmark.synchronizedMax    thrpt        5    5437590,131    651603,805  ops/s
> 
> 8 threads
> Benchmark                               Mode  Samples          Score  Score error  Units
> n.e.j.t.MyBenchmark.atomicMax          thrpt        5  308313078,989  7365995,913  ops/s
> n.e.j.t.MyBenchmark.synchronizedMax    thrpt        5    4808905,027   657214,727  ops/s
> 
> 16 threads
> Benchmark                               Mode  Samples          Score   Score error  Units
> n.e.j.t.MyBenchmark.atomicMax          thrpt        5  295064556,539  28027347,836  ops/s
> n.e.j.t.MyBenchmark.synchronizedMax    thrpt        5    4974286,841     79612,105  ops/s
> 
> 
> I would say one sees that both get slower when the active conurrency gets higher, but
the atomic version is always faster. When there are more threads than cores it even gets a
bit better.
> 
> So I would say it is safe to only replace the synchronized max version with the atomic
one. The further changes like moving it to the stats store and cleaning up the mean calculation
and the synchronized method can be left for later:
> 
> I would actually like to introduce a StatsStore interface where the user can register
their own implementaions. They would have to provide add() and getMean() and getMax() but
they can query all they want from their smart implementation (including percentils and stuff).
> 
> Until then, I attached a more minimal patch for the atomicMax of the borrow (only).

Based on the above, I have no objections to either the minimal patch or
the current patch.

Mark


> 
> Gruss
> Bernd
> 
> PS: code is here: https://gist.github.com/ecki/8350a276caa444a62dce
> 
> 
> 
> 
> Am Tue, 23 Sep 2014 19:11:42 +0100
> schrieb Mark Thomas <markt@apache.org>:
> 
>> On 23/09/2014 17:59, Phil Steitz wrote:
>>> On 9/21/14 7:29 PM, Phil Steitz wrote:
>>
>> <snip/>
>>
>>>> I was not able to demonstrate any consistent performance difference
>>>> in my tests.  The code in trunk was a tiny bit faster on average
>>>> but some runs of the patched code were faster than some runs of the
>>>> unpatched code.  It might be worth just changing the max to be
>>>> "lock free" and seeing if that change by itself makes any
>>>> difference. 
>>>
>>> I did that and still could not demonstrate any improvement.  The
>>> report in the ticket does show monitor contention, though, so I am
>>> ambivalent on this one.  What do others think?
>>
>> Typo: s/Mast/Must/
>>
>> I have often found that for large numbers of cheap operations that
>> monitoring tools are far more overhead than the thing they are trying
>> to measure. I recently spent some time tuning a new Cookie parser for
>> Tomcat and the profiler results were useless at identifying the real
>> bottlenecks. I wonder if that is happening here.
>>
>> I have no objection to the patch if the performance is about the same.
>> Adding max to the StatsStore is likely to be useful elsewhere.
>>
>> Mark
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message