> Not really true; Java forces the generic semaphore implementation, which cannot compete with things like spinlocks. IIRC using synchronized imposed a penalty of about 100ms.
I'm curious: where did you get this number? I'm pretty sure that if it was true, I would have noticed it by now.
Posted Jul 16, 2012 11:01 UTC (Mon) by man_ls (subscriber, #15091)
[Link]
I did my own benchmark, and I am citing from memory. It was a long time ago, things have probably improved a lot since 2004 or so...
Good opportunity for Java update
Posted Jul 16, 2012 16:58 UTC (Mon) by raven667 (subscriber, #5198)
[Link]
Probably 8-)
One thing to point out is that the environments with the most optimization effort being put into them are the JVM and the various JavaScript runtimes. All the resources spent on research and implementation shows, in the different benchmarks I've seen Java and JS tend to bubble up around the top closer to compiled languages than other VM environments like Perl, Python, PHP or Ruby.
Good opportunity for Java update
Posted Jul 16, 2012 21:33 UTC (Mon) by man_ls (subscriber, #15091)
[Link]
I think that my results might have been 100ns per synchronization, not 100ms. Sorry about the confusion; funny how memory can make you twist things around to suit your arguments. So let's check out how things behave in practice.
This bit of data seems to suggest that things have improved about 4-fold since then. My own results are a bit higher than those on the page (core i5; IcedTea6): 0.035s vs 0.002s for 1M synchronizations, suggesting a cost of about 30ns for each synchronization. Calling a synchronized method is even cheaper, about 20ns. Not too shabby...