[concurrency-interest] general performance question

Sergey Kuksenko skuksenko at gmail.com
Thu Dec 22 03:39:58 EST 2011


The question is not about contended/uncontended.
The question is how do you perform measurement (and the presentation
is about that).
As for me - I am expecting the same JITted code in both cases and
don't beleive in difference.
Slightly later, I will find time for looking into code and will write you.

On Thu, Dec 22, 2011 at 12:24 PM, Dr Heinz M. Kabutz
<heinz at javaspecialists.eu> wrote:
> As I said, an uncontended lock is obviously the same.  But what about a
> contended lock?  You don't have tests for that in your slides.
>
> Regards
>
> Heinz
> --
> Dr Heinz M. Kabutz (PhD CompSci)
> Author of "The Java(tm) Specialists' Newsletter"
> Sun Java Champion
> IEEE Certified Software Development Professional
> http://www.javaspecialists.eu
> Tel: +30 69 72 850 460
> Skype: kabutz
>
>
>
> On 12/22/11 10:19 AM, Sergey Kuksenko wrote:
>
> You may look at slides 32-34 here
> http://people.apache.org/~shade/talks/j1-Oct2011-21682-benchmarking.pdf
>
>
> On Thu, Dec 22, 2011 at 2:27 AM, Dr Heinz M. Kabutz
> <heinz at javaspecialists.eu> wrote:
>
>
> My benchmark shows in most cases a small performance gain when you use an
> inner synchronized block.  However, the difference is really very small and
> is only in contended locks.  Uncontended locks are optimized away, so that
> does not count.
>
> On my 8-core machine, I call the methods lots of times with random values
> from a pre-filled array to stop the HotSpot compiler from eliminating my
> code.
>
> If the synchronized block is inside the method, we have the following test
> duration in average and standard deviation.  Times are in ms.  Small numbers
> are good, large numbers bad.  High standard deviation means the results are
> all over the place.
>
> 1 Thread:        20 (1.8)
> 2 Threads:    465 (53)
> 4 Threads:    889 (170)
> 8 Threads:    958 (137)
> 16 Threads:  629 (69)
> 32 Threads:  578 (66)
>
> When the whole method is synchronized:
>
> 1 Thread:        20 (0.5)
> 2 Threads:    488 (45)
> 4 Threads:    920 (145)
> 8 Threads:    1037 (90)
> 16 Threads:  612 (70)
> 32 Threads:  645 (74)
>
> However, as much as I would love these results to prove that my initial
> theoretical explanation was right, I think it's too close to call.  Neither
> is great.  If you want good scalability (which is the *only* performance
> reason you'd care about this) then you want to rather try to avoid locking
> altogether and use non-blocking synchronization constructs.
>
> I hope this helped.  My test code and raw results are available on demand.
>
>
> Regards
>
> Heinz
> --
> Dr Heinz M. Kabutz (PhD CompSci)
> Author of "The Java(tm) Specialists' Newsletter"
> Sun Java Champion
> IEEE Certified Software Development Professional
> http://www.javaspecialists.eu
> Tel: +30 69 72 850 460
> Skype: kabutz
>
>
> On 12/21/11 11:37 PM, Vladimir Ivanov wrote:
>
>
> Vitaly,
>
> No, synchronized attribute doesn't prevent method from being inlined by
> JIT compiler in Hotspot. Lock coarsening(redundant lock elimination)
> optimization [1] [2] in C2 greatly benefits from this.
>
> Best regards,
> Vladimir Ivanov
>
> [1]
> http://java.sun.com/performance/reference/whitepapers/6_performance.html#2.1.2
> [2]
> http://www.google.com/codesearch#Y_pa0sa9c2w/src/share/vm/opto/callnode.cpp&l=1213
>
> On 12/21/11 9:33 PM, Vitaly Davidovich wrote:
>
>
> IIRC, synch on method generates less bytecode but that would only matter
> if the method was on the bytecode size boundary for inlining (I believe
> default is 35 byte codes), but i think synchronization already prevents
> inlining as a heuristic.
>
> On Dec 21, 2011 11:48 AM, "Nathan Reynolds" <nathan.reynolds at oracle.com
> <mailto:nathan.reynolds at oracle.com>> wrote:
>
>    Use javap to check the bytecode output from both.  From a
>    performance perspective, I don't think it shouldn't matter.
>    However, from an API perspective it matters.  Let's say you derive
>    the class and implement someMethod.  If the synchronized keyword is
>    on the method, then Eclipse or FindBugs could be configured to warn
>    you that the overridden method doesn't declare synchronized.  The
>    tool suggests that this means the overridden method is not correctly
>    synchronized.  On the other hand, "synchronized(this)" will trigger
>    Eclipse or FindBugs to warn you that the code is synchronizing on a
>    publicly accessible object.  This means that if another piece of
>    code synchronizes on the object then there might be an unintended
>    scalability problem.
>
>    Nathan Reynolds
>    <http://psr.us.oracle.com/wiki/index.php/User:Nathan_Reynolds> |
>    Consulting Member of Technical Staff | 602.333.9091 <tel:602.333.9091>
>    Oracle PSR Engineering <http://psr.us.oracle.com/> | Server Technology
>
>    On 12/21/2011 8:45 AM, Jha, Navin wrote:
>
>
>    Is there an advantage to do:
>
>    someMethod(...) {
>             synchronized(this) {
>                     ................
>                     ................
>                     ................
>             }
>    }
>
>    instead of:
>    synchronized someMethod(...) {
>    ................
>    ................
>    ................
>    }
>
>    Even when the entire method needs to be synchronized? I understand in
> general it is a good practice to use synchronized blocks since more often
> than not only certain lines need to be synchronized.
>
>    -Navin
>
>    _______________________________________________
>    Concurrency-interest mailing list
>    Concurrency-interest at cs.oswego.edu
>  <mailto:Concurrency-interest at cs.oswego.edu>
>    http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>
>
>    _______________________________________________
>    Concurrency-interest mailing list
>    Concurrency-interest at cs.oswego.edu
>    <mailto:Concurrency-interest at cs.oswego.edu>
>    http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>
>
>
> _______________________________________________
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>
>
> _______________________________________________
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>
>
>
> _______________________________________________
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>
>
>



-- 
Best regards,
Sergey Kuksenko



More information about the Concurrency-interest mailing list