Java VM & .NET Performance Comparisons

← Back to Stories (view on slashdot.org)

Java VM & .NET Performance Comparisons

Posted by timothy on Wednesday October 20, 2004 @05:23AM 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."

10 of 104 comments (clear)

Min score:

Reason:

Sort:

JRocket? by Lechter · 2004-10-20 06:41 · Score: 2, Interesting

I'd also be very curious to see an independent mark of BEA's JRocket JVM, which is supposed to blow Sun and IBM away on X86.

--
credo quia absurdum
Re:GCJ slower than a native JVM? by Hard_Code · 2004-10-20 06:52 · Score: 4, Interesting

Because for that to work, every OS would have to support it, and since actually none DO (except maybe Hurd, which nobody uses), ipso facto, it must be done in the libraries. You could of course argue whether it is done in libraries that are visible to programs, or built into the VM itself but that sort of academic.

Furthermore, I don't think it is necessarily true that everything-is-a-file is the best abstraction for all IO forever and ever. If you want such an abstraction simply use java.net.URL and write protocol handlers for any protocols not provided. So far, http[s]:// and file:// (and probably some others) work out of the box. Add your own.

--

It's 10 PM. Do you know if you're un-American?
Re:GCJ slower than a native JVM? by CaptainPinko · 2004-10-20 06:53 · Score: 2, Interesting

Well I don't that abstracting to a file is actually that good a thing. The problem with treating it like a file is that there are fairly specifc things that seperate files from network streams from devices. For example you never need to worry about a file being disconnected but with devices and networks it is. Having seperate classes allows from more specifc methods methods to be created like isReachable(Address) which can't apply to a file. Trying to merge them all into Object would lead to sloppy semantics (for example if someone deletes a file you are reading are you going to consider that being disconnected and throw a NetworkException?).
If you want to use use one object for them all and completely abstract everything then I think there is a completely in JVM solution: the abstract classes. Abstract classes provided the structure to create the implementation you need but aren'tbound to any one implementation. So create a printFrmoStream (java.io.InputStream) time and you'll get all the abstraction you'd want for both AudioInputStream or FileInputStream. I think Java provides all the transparency you. Either that or I completely misread your question. :)

--
Your CPU is not doing anything else, at least do something.
what test was used for JESS? by Anonymous Coward · 2004-10-20 07:32 · Score: 2, Interesting

I've run probably over 100 benchmarks comparing IBM and Sun jdk for JESS using manners and waltz benchmark. In all of my tests using -server and client for jdk1.4.2, IBM was on average 20-30% faster than Sun. Makes me wonder if there was something specific in the JESS test, which gave Sun the advantage.
excellent for C# by jeif1k · 2004-10-20 08:19 · Score: 4, Interesting

What these benchmarks suggest to me is that C#/.NET is fully competitive in terms of performance with the best Java implementations, and C#/Mono is good enough for most work. In fact, given the additional language features of C#, it may well be easier to write fast code for many compute-intensive problems using Mono than Java today.

The level of performance of Mono is even more impressive given how young the project is; at the same point in time in its evolution, Sun had barely managed to produce a JIT compiler.
1. Re:excellent for C# by jeif1k · 2004-10-21 07:26 · Score: 2, Interesting
  
  My point? You complained about Sun (claiming that Sun claims to have GC options, but that they have implementation problems).
  
  I didn't "complain" about Sun. I simply pointed out that they started out with a pretty poor implementation and that it has taken them a long time to bring it to maturity. I also pointed out that C# is competitive with Sun's much older Java implementations now in terms of performance.
  
  And what would the advantage of that be? Having only one way of accessing data is simpler. Having to decide (in C or C++) between Stack or Heap allocation takes up time and the difference can introduce subtle bugs.
  
  The advantage would be that commonly used data types like complex numbers and 3D vectors behave the way programmers expect them to. If that confuses you, you are right, C# isn't the language for you.
  
  Er... so... Suns implementation, dynamic compilers, GC options were known, when .NET came out. Why does a huge company with huge research resources create such a poor implementation of the CLR?
  
  Gosh, did you even bother to look at the story? Quite uncharacteristically, Microsoft did just about everything right with C#/CLR. Their own implementations are excellent. And, in contrast to Java, the C#/CLR standard is open and there are good open source implementations with extensive libraries. And C# is simply a better designed language than Java. It is also functionally a strict superset, which means that people will likely gradually migrate to CLR (either with a Java/CLR compiler or directly to C#) and never look back.
Re:GCJ slower than a native JVM? by jilles · 2004-10-20 10:04 · Score: 3, Interesting

If you'd know what dynamic compilation is, you'd fully expect the opposite. I'm only surprised by the difference in numbers. GCJ is doing much worse than I expected. From the looks of it, the only times it comes close to competing is when executing simplistic numerical benchmarks (which are presumably easy to optimize). What you are seeing here is that runtime optimization actually works when doing real-life complicated stuff.

The use of the word interpreter is really suggestive. A compiler is nothing more than a static interpreter. The only two differences with a JIT compiler is that it permanently stores the results of the interpretation and that it has much less information to predict the performance of the code it is generating. A static compiler will do well on simplistic programs whereas a run-time optimizing jit compiler will be able to always match the performance of a static compiler (simply by running the same optimizations) or beat it (by applying optimizations to address observed performance bottlenecks in the running program). Of course this costs some computation time but you can take that into account as well when deciding to optimize or not.

In simplistic scenarios such as simple benchmarks, there won't be much to gain from run-time optimization. So performance is about equal with a slight advantage for the static compiler because it is not wasting resources on figuring out how to optimize the program. Despite this GCJ's performance is disappointing even on these kinds of benchmarks.

--

Jilles
API Docs by CaptainPinko · 2004-10-20 10:09 · Score: 2, Interesting

The Java API has a lot of these and that's probably why he has to keep going back to the API docs.
I must say that is mitigated by the fact the Java has hands down the best API documentation for any platform. Really what more could you ask for. Combined with the Swingset and there SWING component guide, who could ask for anything more in terms of documentation? Mind you I'll agree that getting used to all the layers can be a burden when first learning but it becomes elegant once you see the big picture.

--
Your CPU is not doing anything else, at least do something.
Java GUI performance by O · 2004-10-20 11:15 · Score: 3, Interesting

For one of my classes, I've been using Eclipse to do Java development. The CS lab at school has only Windows machines (XP Pro; P4-3.2G w/ HT, I think) and Eclipse runs very nicely on these computers.

At home, I run Linux on a P4-2.6G w/ HT. Frankly, Eclipse runs like ass on Linux. I've tested it with pretty much every available JRE/J2SDK for Linux, and it sucks with all of them.

This is using Eclipse with SWT compiled for GTK+. I have used WebSphere with the Motif libraries, and it was quite fast, but Motif is just horrid to use next to GTK+. But, SWT with GTK+ is just so damned slow. I've run Eclipse on my PowerBook G4, and it sucks even more on Mac OS.

I find this funny that Windows is the best supported platform for Java GUI programs, considering that MS hates Java. So, is GUI performance with Java apps ever going to be acceptable on Linux? It's really pathetic at this point.

I know Sun added OpenGL 2D acceleration to their 1.5.0 JRE, but that gives me lots of artifacts with the included demo programs, and SWT doesn't use the acceleration at all.

--

1, 1, 2, 3, 5, 8, 13, 21 -- Mathematics is the Language of Nature.
Re:Also... by Anonymous Coward · 2004-10-20 17:58 · Score: 1, Interesting

For example, template classes used with primitive argument types are much more efficient in C#.

If you want to use a macro preprocessor with Java, there is nothing stopping you from doing so. The fact that the base language doesn't include a macro system is immaterial, as there are many external alternatives.