> 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.
I 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.
If 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.
I 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 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)
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. ;-)