0

Someone told me there was more overhead for Java because you can essentially run it on most operating systems and that C# doesn't have that overhead so then it can execute at near C++ speeds.

So is there more overhead in Java, or does each OS has it's own overhead for it's JVM implementation?

Adam C.
  • 11
  • 4
  • 3
    _Both_ JVM and .NET are multiplatform. That has nothing to do with its runtime performance, at any rate. .NET tends to rely more on ahead-of-time compilation (via `ngen`), whereas JVM tends to rely more on just-in-time compilation, but both can provide near-native speeds. – C. K. Young Aug 08 '14 at 01:47
  • Doesn't C# run in it's own VM? – MadProgrammer Aug 08 '14 at 01:47
  • I guess he means that C# is more or less suited towards Windows. And yes, C# has its own VM. He's saying that since Java is built more towards multiplatform rather than Windows, it has more overhead. – Adam C. Aug 08 '14 at 01:50
  • @AdamC. C# is _not_ Windows-specific by any means, and in fact Mono and Xamarin provide .NET for many platforms, including mobile. – C. K. Young Aug 08 '14 at 01:51
  • C# isn't windows specific, but many of the libraries one would typically use in a Windows C# environment are very windows specific. If you want portability with C#, better to develop on Mono and then port back to Windows. The other way is more painful. – Edwin Buck Aug 08 '14 at 01:57
  • I sincerely doubt that C# can outperform Java in most operations that do not involve OS and network interactions. – Hot Licks Aug 08 '14 at 02:00
  • 2
    The statement doesn't make sense. Cross-platform implies there is a set of library implementations for each platform, and a JVM. It doesn't have anything to do with the language *per se,* or with execution speeds. – user207421 Aug 08 '14 at 02:03

2 Answers2

8

C#, Java (and I'll toss it in there too - JavaScript) are languages. Languages are not fast or slow, they just are specifications for how we humans write things that are to eventually be handled by a computer.

The JVM is the Java Virtual Machine. But there are several different versions of it. There's HotSpot (the original), OpenJDK, And then one can look at JRockit from BEA, Apache Harmony and a bunch more.

For C# there is the CLR, but there's also Mono's runtime. There are also others that have been abandoned over time.

JavaScript (because I'm tossing that in there) has an entire army of runtimes. Some of those runtimes are faster than others.

It is the runtime that is faster or slower than another - even possibly for the same language. But that one is 'cross platform' and another is not is not enough of an indication to say that one is faster than the other. There are a great many other things at work and benchmarks can be constructed that show one combination being faster than another for each one.

Going even further, one can look at languages that span multiple runtimes. You've got Python with CPython as its default implementation - but there's Jython that runs in the JVM and IronPython that runs in the CLR. Similar examples can be found with Ruby, IronRuby, and JRuby or Clojure which can be compiled to JavaScript via ClojureScript and then run on one of the JavaScript runtimes rather than a JVM.

Again, its not the language that is fast or slow - but rather how its implemented in its runtime.

C. K. Young
  • 219,335
  • 46
  • 382
  • 435
  • Even with the JVM there are multiple different implementations, not just from Oracle (sun). There is also the OpenJDK and commercial implementations from IBM and others. – Brett Okken Aug 08 '14 at 02:06
  • 1
    And it doesn't stop there. Other languages like Ruby have many different runtimes (some of which actually run on the JVM), and even compiled languages like C, C++ or FORTRAN have many different compilers, some of which generate code that runs faster than others. – Michael Dorst Aug 08 '14 at 02:10
  • @BrettOkken thank you for reminding me - it completely slipped my mind despite working with JRockit in the past that it was its own JVM too. –  Aug 08 '14 at 02:10
  • Runtimes may vary, but it's wrong to say that a language's semantics have no effect on its speed. Compare method calls in C++ and Python. In the non-virtual case, a C++ method call is effectively a C call with a zeroth parameter. This is trivial to implement as a series of pushes followed by a call. On the other hand, Python requires a hash lookup to find the variable, another hash lookup to find \_\_call__, more lookups to find arguments, and it gets worse from there. If you can prove the work is unnecessary you can skip it, but you can't always and this definitely affects performance. – Steve McKay Aug 08 '14 at 02:35
  • @SteveMcKay I will admit to significant oversimplification there. One can point to thinks like [look, JRuby is faster than Ruby for for fannkuch-redux benchmark](http://benchmarksgame.alioth.debian.org/u64q/jruby.php) or [Clojure is faster than Java for k-nucleotide](http://benchmarksgame.alioth.debian.org/u64q/benchmark.php?test=all&lang=clojure&lang2=java&data=u64q). But python vs C++ isn't exactly a fair test as is. It might be interesting to get a [python to C++ compiler](http://shed-skin.blogspot.com) and run those tests again. because thats still python there (different runtime though). –  Aug 08 '14 at 19:10
  • @MichaelT How is Python vs C++ not a fair test? Performance is explicitly part of C++'s design ("you don't pay for what you don't use"), and it's not emphasized nearly so much for Python. Shed Skin is a subset of Python, excising the parts that are difficult to implement efficiently, like ["eval, getattr, hasattr, isinstance, anything really dynamic"](https://code.google.com/p/shedskin/wiki/docs#Python_Subset_Restrictions). – Steve McKay Aug 08 '14 at 21:26
  • @SteveMcKay Mono doesn't have everything that is part of C#, Jython doesn't have everything hats parts of CPython. My point is more one of 'the runtimes on those two are so dissimilar' that you are not really comparing the two languages. Fundamentally different languages in different runtimes has no control between them. One might want to compare it under CINT instead. The point I am trying to make is the language that is fast or slow. The C++ native vs Python comparison is two very different approaches to how to run a program - and *those* can be faster or slower. –  Aug 08 '14 at 21:37
  • @MichaelT The point that I'm trying to make is that the design of a language has an extremely strong influence on the difficulty of producing an efficient implementation of the language. This influence is strong enough that it's definitely valid to classify a language as slow when [no known implementation technique will produce an efficient implementation](http://c2.com/cgi/wiki?SufficientlySmartCompiler). – Steve McKay Aug 09 '14 at 00:58
  • @SteveMcKay If we take, say Objective C and C and compare them compiled to the same target, then yes - the dynamic features of Objective C with its runtime will be slower than C. However, returning back to the OP's question - there is nothing in Java or C# that makes *the language* slow when compared to each other. There *are* some things in the runtime that one may be able to optimize given various restrictions. Its possible to run [Java in Mono](http://www.ikvm.net) and it would be interesting to see what performance is like... but again, a language is not fast or slow, an implementation is. –  Aug 09 '14 at 01:23
2

The Java language and the Java Virtual Machine (JVM) are completely separate entities. Oracle has done an excellent job of separating the two, so that other languages (like Scala or even Ruby) can run on the JVM.

The Java language itself is definitely written with the intent of targeting the JVM, but, so far as I know, there is no actual requirement that it must. So far as I know it's completely possible to write a Java compiler that generates native code, rather than Java bytecode. (This is all completely hypothetical. I've never heard of anyone actually doing that - there would be very little point. Current implementations of the JVM tend to be almost as fast as native code, and any benefit gained by this would be greatly outweighed by the loss of portability it would entail.)

The situation is further complicated by the fact that C# doesn't exactly have a VM, as discussed here. So the best comparison you can make is "does this implementation of the JVM run this Java code faster than that implementation of the .NET framework runs that C# code?"

In the end, unless there is a remarkable speed difference for very similar code, the comparison just isn't that compelling because there are too many variables. Use a different JVM, or a different Java compiler, or a different .NET implementation, or a different C# compiler, or run the same code on a different machine, and the numbers change.

Community
  • 1
  • 1
Michael Dorst
  • 8,210
  • 11
  • 44
  • 71
  • 1
    GCJ produces native code. It never got much traction, though, and I imagine OpenJDK took away almost all of its reason for existing (GPL javac). – Steve McKay Aug 08 '14 at 03:05
  • That's interesting. What was its reason for existing and why did OpenJDK take it away? – Michael Dorst Aug 08 '14 at 05:18
  • @SteveMcKay [Excelsior JET](http://www.excelsiorjet.com) appears to still be doing reasonably well. Granted, its not open, but it is a Java to native code compiler. –  Aug 08 '14 at 13:48
  • @anthropomorphic Javac was originally proprietary. IIRC eventually Sun released the source but under a non-free license. The purpose of GCJ was to be a free software javac, paired with GNU Classpath to create a free software Java runtime. Now that you can get the Java reference implementation under the GPL, a lot of the ideological justification for GCJ and GNU Classpath has gone away. – Steve McKay Aug 08 '14 at 21:30
  • I've known Java to machine language compilers for doing parallel computing in university settings as well (although they did use an intermediate language, but that is common). – Maarten Bodewes Aug 10 '14 at 00:58