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 <ma...@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-unsubscr...@commons.apache.org
>> For additional commands, e-mail: dev-h...@commons.apache.org
>>
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
> 


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

Reply via email to