Measuring performance changes from applying 4837946 patch (original) (raw)

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