5 ms·
I can comment on the JRuby results. For the base perf numbers, I'm not surprised. We've known that we're roughly on par with 1.9.2 for some time, and many of t
by headius 16y ago
I can comment on the JRuby results.
For the base perf numbers, I'm not surprised. We've known that we're roughly on par with 1.9.2 for some time, and many of the benchmarks in question have started to reach a point of irreducible complexity (e.g. you can only slice and dice strings so fast). It's good to see JRuby remains at or near the front of the pack as far as performance, especially considering we've made no major performance-related changes in almost two years.
The Linux versus Windows numbers are a bit surprising to me. If I were to make a guess, I'd guess that the JVMs used were not identical (perhaps like Isaac Gouy mentions, one platform was 64-bit and the other wasn't) or some other detail altered the performance characteristics of the test. But the performance drop does seem to be in line with other implementations, so perhaps Windows really does suck and there's not much we can do about it.
On the memory issue, I have a few recommendations.
JRuby by default allows the JVM to use up to a 512MB heap (the default is usually 32-64MB, which is rarely enough for most nontrivial apps). The JVM likes to use as much memory as you're willing to give it, to keep GC times low (nearly free) and to give it lots of room to breathe. Almost all these benchmarks could run in far less memory (maybe 1/5 as much or lower) if the JVM were choked down to that level. So it's not surprising to me that the memory sizes for these very object and CPU-intensive benchmarks start to approach that 512MB limit; the JVM is just stretching its legs.
Expect to see a lot more performance work coming in JRuby 1.6. I've blogged about it here: http://blog.headius.com/2010/05/kicking-jruby-performance-up-notch.html http://blog.headius.com/2010/05/kicking-jruby-performance-up...
Also expect to see more work on picking a "winner" as far as lightweight servers go. Something that works as seamlessly as Passenger could be the "last mile" we need to get folks to make a move.
And watch our two Ruby Summer of Code projects: Ruboto, bringing JRuby to Android; and C extension support.
We're working very hard to bring JRuby to everyone and everyone to JRuby. The reasons not to use JRuby are rapidly disappearing.
- deleted 16y ago[deleted]
- acangiano 16y ago> The Linux versus Windows numbers are a bit surprising to me. If I were to make a guess, I'd guess that the JVMs used were not identical (perhaps like Isaac Gouy mentions, one platform was 64-bit and the other wasn't) or some other detail altered the performance characteristics of the test. The same identical version was used: Java HotSpot(TM) 64-Bit Server VM 1.6.0_20. > But the performance drop does seem to be in line with other implementations, so perhaps Windows really does suck and there's not much we can do about it. The leading theory. ;-)
- xpaulbettsx 16y agoI don't know that this theory totally holds water (Windows OS developer here, announcing obvious bias) - looking at the results, the one place Windows really gets nailed is the I/O test; I suspect there's some significant optimizations that could be done there, as I/O on Windows OS in general certainly isn't 4x slower than Linux.
- headius 16y agoIf there's something we or the JVM could do to improve these numbers, I would love to talk to you about it. At this point, if the JVM developers haven't found the magic sauce, we JRuby guys probably won't either...but I'd really love for JRuby performance on Windows to match JRuby performance on Linux.
- xpaulbettsx 16y agoI don't think that I can actively hack on the JVM, but I can tell you that XPerf is a great way to determine where you're spending your time. http://www.microsoftpdc.com/2009/CL16 http://www.microsoftpdc.com/2009/CL16 is a really good intro video on the topic, it's a very powerful tool (though doesn't provide as much analysis as Instruments for example)
- donw 16y agoTooting my own metaphorical horn a bit, but it was relatively easy to put together a Jetty-Rack interface for high-performance webapps. It's called Mizuno, and lives at http://github.com/matadon/mizuno http://github.com/matadon/mizuno Internally it uses Jetty's event-driven I/O, so performance is on a par with Thin and Passenger, at least on my MacBook. I'm a bit pressed for time at the moment, so if anybody wants to add in the cometd servlet (it's in the repos) and write a tutorial, that'd be awesome, and if not, I'll get to it in a few weeks.
- headius 16y agoSounds pretty cool :) I'd love to see some blog posts about it, but I doubt I'll have time to do so in the next couple weeks.
- necubi 16y agoI'm very excited to see C-extension support. That might finally convince me to port some of my projects.