3

Not so long ago I was told by a senior academic that, these days, VM-based code could run nearly as fast as compiled code, but my own experience is that compiled code runs several orders of time faster.

This is based on code attempting to do the same thing (processing a very large XML file) - in the case of the VM-based code (Groovy) I guess my code would complete in about two years (correct) whereas the C/C++ based alternative took about three hours.

The algorithms were not quite the same - but that was because using C/C++ allowed me to manipulate the memory at a byte level using pointers. The Groovy code was easier to write as the language was much more expressive, but the price paid was slow execution.

I don't claim to be the world's greatest coder so I would willingly accept that my code could have been improved: but what is the general view?

closed as too broad by gnat, Kilian Foth, user53019, user40980, Bart van Ingen Schenau Feb 28 '14 at 11:23

Please edit the question to limit it to a specific problem with enough detail to identify an adequate answer. Avoid asking multiple distinct questions at once. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.

  • 3
    Interesting title, but you're trying to compare apples and oranges. If your algorithms are different you can't get meaningful comparison results. – Christian P Feb 27 '14 at 10:32
  • @ChristianP: I guess the OP does not really mean "entirely different algorithms" - he probably means in C++ he could add some bit-level optimizations to the algorithm not available in groovy. – Doc Brown Feb 27 '14 at 11:28
  • @ChristianP is correct. The task was the same, some bits of the algorithm differed. – adrianmcmenamin Feb 27 '14 at 14:11
  • Well, it would be interesting how much you had to change the original algorithm to gain a >5000 fold speed increasement. Are you willing to give us some more details? – Doc Brown Feb 27 '14 at 14:15
  • @adrianmcmenamin maybe you could make a benchmark of C++ code with and without optimizations so you can measure how much performance gain did you get with this optimizations. – Christian P Feb 28 '14 at 8:06
4

Actually, Google published a paper around two years ago about this topic which describes what you have noticed here. C++ programs allow typically more optimizations than programs written in languages like Java/Scala/Go (or in your case Groovy), which gives more opportunities to make them faster - but for the price of increased programming effort.

Said that, a speed factor of >5000 is to my experience very unusual. A factor between 2 to 20 is what I have noticed in the past (depending on the problem and the "other language" to be compared with C++). Such a factor indicates that there is a good chance of optimizing your Groovy program by at least one or two orders of magnitude without changing the language. www.stackoverflow.com would be the place to discuss certain optimization issues (provided you are willing to post some core parts of your code there).

  • If your code is 2-20x slower, and uses a library that is 2-20x slower, which uses an XMl parsing library which is 2-20x slower, which uses a standard library wich is 2-20x slower, eventually you hit the point where it matters... – soru Feb 27 '14 at 11:55
  • Java allows similar optimizations to C++. It uses more of virtual dispatch which does not allow inlining, but catches up on just-in-time. Groovy, however, allows much less optimization because it is dynamic. – Jan Hudec Feb 27 '14 at 12:20
  • @soru: I cannot remember having seen a real world case where these factors multiply the way you pretend. But I have seen lots of real world cases where one of such factors was dominating the others. – Doc Brown Feb 27 '14 at 13:55
  • 2
    @JanHudec: I don't like holy wars about "Java vs. C++" performance (for me, Java and C# are just fast enough for most cases). But a factor of >5000 seems very extreme even for a dynamic language vs. C++. – Doc Brown Feb 27 '14 at 14:09
3

Performance of C, C++ and Java are comparable. Java is sometimes even faster though usually it is a little bit slower.

However dynamically typed languages (which Groovy is) are slower, because they have to look up member and methods all over all the time while statically typed languages can do it in advance and just use appropriate offsets.

Of course if you are making it further slower by using different algorithm that involves more copying, you are no longer comparing the speed of the languages. But some algorithms can only be used in some languages, which counts to their advantage. That is mainly the case of anything that relies on C/C++'s weak typing where you can take a piece of memory and tell the compiler to treat it as any type you want. No dynamic language can do that and most managed languages (like Java) can't do that either.

Note, that this applies independently of whether the dynamic language is run on a VM or compiled to native code. Most dynamic languages are run on VMs, but there are compiled ones too and they are all slower then statically typed ones.

  • 1
    Dynamically typed languages are also slower because they need to do type-checking at runtime constantly. But, yes, if he used a different algorithm that throws the comparison off completely. – Doval Feb 27 '14 at 11:01
  • Actually, the HotSpot JVM doesn't really do anything very interesting with the static types in the byte code. Almost all of HotSpots optimizations are dynamic and make no use of static type information, which isn't terribly surprising considering that it is basically a slightly modified Smalltalk VM. – Jörg W Mittag Feb 27 '14 at 11:50
  • 1
    @Doval: The "type-checking" of dynamic languages is really looking up methods. Because everything is an "object", it just may or may not have the method you are trying to use. – Jan Hudec Feb 27 '14 at 12:21
  • @JörgWMittag: The HotSpot does not, but the compiler does. The byte-code has fast way to call methods by index if the type is known, but Groovy is left with only the slower introspection way. – Jan Hudec Feb 27 '14 at 12:26
  • @JanHudec You're assuming everything is an object. That's not necessarily the case. – Doval Feb 27 '14 at 12:41

Not the answer you're looking for? Browse other questions tagged or ask your own question.