Measuring performance changes from applying 4837946 patch
brian.burkhalter at oracle.com
Tue Jun 4 17:47:44 UTC 2013
On Jun 4, 2013, at 1:36 AM, Aleksey Shipilev wrote:
> On 06/04/2013 04:27 AM, Brian Burkhalter wrote:
>> A) Is there some particular approach that should be used in testing
>> these algorithms for relative performance?
> The number one approach is peer review. Is there the JMH project with
> microbenchmarks somewhere? Sergey (cc'ed) knows a lot about
> BigInteger/BigDecimal performance, and particular quirks you might be
Abbreviated code posted to this forum.
>> B) Could there be something platform-dependent happening?
> It does not seem likely for pure Java BI/BD benchmarks. Thread
> scheduling might affect the results; but this seems to be non-essential
> for single-threaded benchmarks.
Thanks for confirming this.
>> C) As currently implemented, the relative performance between
>> algorithms should be unaffected by thread count, correct?
> Nope, that is generally incorrect:
> a) allocation patterns are different; you can hit the allocation wall
> with multiple threads (which is realistic for highly-loaded systems);
> the algorithm allocating more temporal objects may be faster in single
> thread, but slower in multiple threads
> b) the cache contention effects might be more pronunciated with more
> threads hitting the same caches
> c) CMT-enabled machines will have significantly different performance
> with thread count exceeding the number of cores;
> d) thread schedulers are known to cause weird decisions for the thread
> layout when there is the liberty of distributing N threads over M
> hardware threads (N < M)
I should have been clear that I never used more threads than the number of cores, viz., two.
More information about the core-libs-dev