| |||||||||||||
Good opportunity for Java updateGood opportunity for Java updatePosted Jul 16, 2012 16:58 UTC (Mon) by raven667 (subscriber, #5198)In reply to: Good opportunity for Java update by man_ls Parent article: Galaxy in-memory data grid released
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.
(Log in to post comments)
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... My updated code yields: 1M computations: 0.035s 1M synchronized code blocks: 0.004s 1M synchronized method calls: 0.023s
|
|||||||||||||