Slashdot Mirror

← Back to Stories (view on slashdot.org)

Java VM & .NET Performance Comparisons

Posted by timothy on from the cool-your-jets dept.

johnhennessy writes "Just came across some good virtual machine performance benchmarks (on Mono's mailing list). It covers executing java bytecode via a host of different Java runtimes and also the mono runtime. Not only does it give numbers for IBM's runtime (1.4.2 and 1.3.1), Sun's runtime (1.5.0 and 1.4.2), GCJ, Mono, Jikes and much more! These numbers are also given for both Intel and Opteron (where relevant). Before the flames begin, don't forget to read the authors description of how the benchmark was carried out. Hopefuly this should inspire educated discussion on ones favourite JVM/CLR."

6 of 104 comments (clear)

  1. No jRocket by Anonymous Coward · · Score: 2, Insightful

    These are nice evaluations of "free" JVMs.
    But I don't see commerical and highly optimized products like JRocket on there (BTW, I think the JRocket JVM is free, support costs).

  2. Re:Sun's JDK most powerful, no surprise. by Profane+MuthaFucka · · Score: 3, Insightful

    Everyone else knows it as well as Sun. The language and VM spec are public knowlege.

    Sun has a better JVM not because they have some mystical insight because they invented it, but because they made it a huge part of their company survival strategy. Improving the JVM gets a very high priority in the company. IBM on the other hand might not care if they are second, as long as their performance is competitive.

    --
    Fascism trolls keeping me up every night. When I starts a preachin', he HITS ME WITH HIS REICH!
  3. GCJ slower than a native JVM? by Muad'Dave · · Score: 2, Insightful

    What surprises me is that GCJ is never faster than a 'real' JVM. You'd think that natively compiled and optimized code would be faster than an interpreter. I guess there's optimization work to be done in gcjlib.

    --
    Tiller's Rule: Never use a word in written form that you've only heard and never read. You will end up looking foolish.
    1. Re:GCJ slower than a native JVM? by CaptainPinko · · Score: 4, Insightful

      Yes you are crazy. Don't use java then. Really when I look at C functions I think they are an awful mess of vomit, however I except that this is the aesthetic/style that C expect and I deal with it. If you worked with Java enough you woudln't have to look it up. What I like about java is that since there are so many layers I can take out the FileInputStream reader and throw a NewtworkStream and leave the rest of the code the same since it uses the buffered reader. For exapmle in C i hate how there is fprintf, sprintf, printf. As far as I am concernred those should be all rolled into one function. The point is either except the way that Java is or don't use it: don't make Java like C. I'm sure you can see how much you'd hate C if I tried to make it more like Java.

      --
      Your CPU is not doing anything else, at least do something.
    2. Re:GCJ slower than a native JVM? by Fnkmaster · · Score: 2, Insightful

      Agreed 100%. There are things that annoy me about Java, but the IO classes are a godsend. I rather miss their flexibility and power when I'm working in C, C++, or even Python et. al. Not saying you can't find libraries that have many or most of the capabilities, but in Java, it's all built in and you know it will work on any Java platform.

  4. Re:Sun's JDK most powerful, no surprise. by jeif1k · · Score: 3, Insightful

    It's no surprise Sun's JDK seems to perform the best out of the other versions. They know Java the best since they created it,

    The techniques necessary for compiling Java well have largely been around since long before Sun even released Java. Sun has no special, secret knowledge there, they have just been hacking on their implementation longer than anybody else. If anything, Sun's progress on Java has been pokey.

    Sun Java is probably pretty close to what is theoretically possible, so they will largely be standing still, while other implementations will keep improving until they also hit the limit. In a couple of years, you can expect that all actively developed JVM and CLR implementations will have roughly the same performance on comparable code.