Measuring performance changes from applying 4837946 patch

[Brian Burkhalter]

Hi Aleksey,

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
> seeing.

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.

Thanks,

Brian