Measuring performance changes from applying 4837946 patch

Aleksey Shipilev aleksey.shipilev at oracle.com
Tue Jun 4 08:36:31 UTC 2013


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.

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

> 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)


-Aleksey.



More information about the core-libs-dev mailing list