10 ms·

It's pretty astonishing how easily C++ trounces everything else including Java. I guess there's still something to be said for compiling directly to optimised b

• Yorrrick 12y ago
  Compilation method isn't what's going on here. Static type systems are, as explained in the article.
• mtdewcmu 12y ago
  Supposedly, Java is going to be faster than native code any day now. It's been said for years. The case was somewhat credible at one time, because the opportunity exists to optimize using runtime information. I think the reason it didn't go that way is: 1. CPUs have gotten very good at doing runtime optimization kinds of things on their own, like predicting branches and reducing the cost of virtual function calls. 2. Java only does optimizations that can be done quickly, since the optimizer has to compete with the executing program itself. 3. The claim was overblown to begin with, and Java is trying to do too many other things, like be secure, that interfere with performance.
  • Afforess 12y ago
    I have never seen Sun or Oracle make that claim. You seem to simply be ranting on about a strawman argument, with a rather strange java-hate obsession. I mean, Fortran did worse than Java. Where is your writeup for that?
    • mtdewcmu 12y ago
      Actually, I made fun of Fortran for that down below. I don't think my comment is a rant.
    • georgemcbay 12y ago
      There was certainly a lot of talk within the Java development community about how Java was going to meet or overtake native code as the HotSpot VM matured. See, for example (from 1998): http://www.artima.com/designtechniques/hotspotP.html http://www.artima.com/designtechniques/hotspotP.html "According to Sun Microsystems, the Hotspot virtual machine, Sun's next-generation Java virtual machine (JVM), promises to make Java "as fast as C++.""
      • kbenson 12y ago
        I wonder how well modern JVMs compare to C++ compilers from 1998?
      • mtdewcmu 12y ago
        There's nothing wrong with trying to sell your product. But I hope Sun's salesmanship doesn't continue to deceive people.
      • cbsmith 12y ago
        I'd say that statements like that are subject to some degree of interpretation. It's hard for one runtime to be definitively faster than another runtime. It is, however, quite possible for one runtime to have cases where it is better, cases where it is worse, and cases where it is equivalent such that it is reasonable to say that it is "as fast as" the other. Java tends to be a bit slower than C++ still, but the differences between it and "as fast as" are trivial enough that a number of HFT systems, for example, are written in Java.
        • kbenson 12y ago
          While I think the comment here leaves that open as a possibility, the second sentence of the article it's from makes it pretty clear. "Specifically, Sun says that a platform-independent Java program delivered as bytecodes in class files will run on Hotspot at speeds on par with an equivalent C++ program compiled to a native executable." There's not a lot of wiggle room there.
          • cbsmith 12y ago
            Actually, there is a country mile of wiggle room there. It doesn't have to be true of all programs for one, and "on par with" gives you plenty of wiggle room.
          • jdmichal 12y ago
            Considering that I can get different performance for the same C++ program simply by using different compiler, or even different compiler options, I'd say that there's a lot of wiggle room.
    • kmavm 12y ago
      Cliff Click, a smart man in whom I see many admirable qualities, than whom there are few more complete experts on the JVM, gave a tech talk at Facebook about how Java is faster than C++ just a few months ago. Tons of perfectly smart engineers sat and took it seriously. Much of the content was a rehash of this older discussion: http://www.azulsystems.com/blog/cliff/2009-09-06-java-vs-c-performanceagain http://www.azulsystems.com/blog/cliff/2009-09-06-java-vs-c-p... There are plenty of serious, technically deep people trying to convince their colleagues that Java is as fast as C.
      • frik 12y ago
        I know a professor who worked on HotSpot Java VM in early 2000s. He is a smart man, but he always makes these false claims how Java will be as fast as C++ the next years. He was the boss of a local Oracle Labs company, though he left that company recently and is now an C# advocate and make similar claims in favor of MS. Such persons are quite annoying as they try to influence a lot of students.
        • puppetmaster3 12y ago
          Agree. Some kind of group hope, a part of issue w/ the Java lang. Data points in the other direction: http://benchmarksgame.alioth.debian.org/u32q/java.php http://benchmarksgame.alioth.debian.org/u32q/java.php
      • igouy 12y ago
        "Sieve of Erathosthenes"
  • alayne 12y ago
    Java's performance relative to other commonly used languages is very good. It's basically been at 2-3x slower than C/C++ for quite a while.
    • mtdewcmu 12y ago
      It is very good. But it's not quite fair to compare it to, say ruby or PHP, because it still requires a compilation step, and it's still pretty demanding on the programmer.
    • cbsmith 12y ago
      2-3x slower? I guess it depends on what you're doing. For a lot of code I've dealt with the differences in performance have been factional.
      • mtdewcmu 12y ago
        Only computation-heavy code will show a difference. And the disparity is going to vary a lot. Some code will be easy for Java's optimizer and won't give C++ any advantage.
        • cbsmith 12y ago
          Some will even put C++ at a disadvantage.
          • hatred 12y ago
            Out of curiosity any such examples ?
            • cbsmith 12y ago
              Of course there are, and it only takes a few seconds with Google to find them. Here's one: the frannkuch-redux benchmark at http://benchmarksgame.alioth.debian.org/u64q/java.php http://benchmarksgame.alioth.debian.org/u64q/java.php gives Java a >20% CPU efficiency advantage over C++.
  • AnimalMuppet 12y ago
    Maybe 5 years ago, I wrote a mancala game in C++ and Java. The minmax part was maybe 10% slower in Java.
    • mtdewcmu 12y ago
      The type of code makes a big difference in how it will perform relative to C++. You also have to be somewhat expert in each language. You can write arbitrarily slow code in any language. It's not easy to be sure that you're giving each language its best shot.
  • cbsmith 12y ago
    > Supposedly, Java is going to be faster than native code any day now. You'll note that the FORTRAN native code is indeed beaten by Java.
    • mtdewcmu 12y ago
      It's worth remembering that native code isn't fast automatically. An unskilled programmer, for instance, could easily write C++ that's slower than Java. There are a few possible reasons Fortran wasn't faster: 1. Fortran's compilers haven't advanced at the same rate as other languages due to its lack of popularity. 2. Fortran is inherently harder to optimize. 3. People have forgotten how to write fast Fortran, since no one uses it anymore. I don't know which it might be.
      • tbirdz 12y ago
        Fortran is actually easier to optimize than C or C++, as procedure arguments and variables cannot alias each other. Since C99, you can use the restrict keyword to enforce aliasing rules, but many C programmers don't do this, and the restrict keyword isn't even in C++.
        • praseodym 12y ago
          But then again, things like the restrict keyword don't matter that much, except when using specialised compilers (e.g. for DSP chips).
          • cbsmith 12y ago
            Um no. It's a huge deal for heavy duty computational code, so much so that most performance oriented numeric libraries have extra code to workaround the case where restrict is not available..
      • aeroevan 12y ago
        This was probably more of a case of 3. Fortran compilers have been making quite some progress (particularly ifort, but gfortran isn't bad recently). And due to the way multidimentional arrays are built into the language, aliasing isn't nearly as much of an issue for aggressive optimizations.
  • gsnedders 12y ago
    Also profile-guided optimization is ever more widespread with C/C++ compilers, which certainly wins some of the gains you'd normally only expect from the JITing VM.
    • pkolaczk 12y ago
      C++ PGO can do less than JVM JIT does. E.g. JVM JIT takes into account actual configuration options chosen by the user and actual, not predicted workload. This can help e.g. with inlining, because JIT can see only one particular implementation of something was loaded by the user, and optimize for just that case. C++ PGO profiles for a single workload and config chosen by the program creator, which may or may not match what user is doing.
      • CountSessine 12y ago
        In practice, PGO with C/C++ gets most of the really valuable low-hanging fruit, provided the test cases aren't too far off from a typical workload. Also, the JVM JIT needs a steady-state workload to make good guesses about it's optimizations - if it JITs a bunch of methods and then the load changes such that the optimizations no longer apply (loops iterate differently, inlined methods don't get called as much), the JVM's runtime optimization can be foiled. JITting a very heterogenous program can trick the JVM into finding a local-minimum in native performance (which I guess is still a lot better than actually interpreting java byte code).
  • tagrun 12y ago
    I can't see it happening even in a far future except maybe for some artificial microbenchmarks. Java programs use a lot of memory, and since everything is allocated on the heap garbage collection is an issue, impacting real-world programs. In terms of raw CPU speed, access to vector instructions directly can be game changer in various applications. Also C/C++ compilers are also getting better each day.
    • rdtsc 12y ago
      > Java programs use a lot of memory, and since everything is allocated on the heap garbage collection is an issue, impacting real-world programs. That is a very good observation. Looking at back in the past at some point memory speed wasn't that much slower than CPU speed (rather because CPU speeds were not that fast then). So then throwing more memory at something seems like a very good way improve performance. Like say following long chains of pointers through some nested structure or long linked list was ok. At some point CPU speed went through the roof and left memory access speeds behinds. So then caches became very important. Cache aware programming was a "thing". That, coupled with lots having virtualized/cloud machines everywhere that have limited memory kind of turned that initial thinking on its head. Small memory footprint became a desirable trait. Just like in the old MS-DOS & Turbo Pascal days. Java sort of flourished and grew in that time period where "throw more ram at it to get performance" was a very obvious thing to do. Now I think it is less obvious that is the best way. (And perhaps Java's current or future GC and JIT strategies will start to take into account caches and memory frugality better). Now that said I am still amazed at how it can achieve such great performance given all the stuff it does behind the scenes. It is not faster than C but heck, it is very fast still.
      • wbl 12y ago
        Java still lets you make a giant array and operate on that. For high speed numerics programming you do that in every language: FORTRAN, C, Java, etc. At that point comes down to how much information the compiler and you can share: restricted pointers, use assembler kernels, etc.
  • brazzy 12y ago
    No, what happened is mainly that memory access has become a big bottleneck for most programs, and small footprint and cache-friendliness can easily mean a speed difference of 20x. For a number of reasons (such as Object overhead, UTF-16 strings, lack of true object arrays), it is very hard to write small-footprint cache-friendly code in Java.
    • xxs 12y ago
      The mistake is using small objects since Java doesn't have structs and cannot really peel objects under normal circumstances. If I had to write Java code for benchmark I'd just use a long array and represent the state in a long (not a java.lang.Long) Writing really cache friendly code in Java requires to look at the problem orthogonally and use int[]/long[] instead of a small Object with 3 small ints. The Java version simply features some quite horrific code but can easily be run in parallel - no one mentions that. Using streams in pure functional way w/o the parallel in mind is a ritual suicide. Finally, The CPU running benchmark has only 2 cores which is a disadvantage with tons of allocation and garbage.
    • anon4 12y ago
      Object inlining might be the next big thing for the JVM. It can already inline functions, but it can't inline member objects in containing objects, or convert your Integer members to int members, or convert an array of Objects into an array of structs. Converting Object[] arrays into single chunks of packed members when they're all the same type would be a pretty big win by itself.
  • pling 12y ago
    People don't use Java because it's fast. They use Java because it's fast enough, easy, safe, reliable, easy to instrument, easy to debug, has wonderful tool support, is mature, has many tested and heavily used frameworks, has a free chunk of code to do anything you can imagine you can just snag via maven, integrates with everything, works on all major platforms and costs nothing. That makes it fast in other ways.
• gcv 12y ago
  Having dealt with trying to make Java run within some reasonable margin of C++11, I'm not surprised at these results at all. It's really hard to make Java go that fast. I'm instead shocked that the C++ version beat Fortran.
• xxs 12y ago
  The main issue is that C version is hardly functional programming: stuff like array<int,3> for forest and then counting instead of massive branching like java's isStable(); Reserving the entire next_forests like that: next_forests.reserve(forests.size() * possible_meals.size()); helps quite a lot compared to the small header-full instances Java features.
  • hiker 12y ago
    I don't see how the use of std::array<int,3> and std::count makes the C++ version less functional. Also, the next_forests.reserve doesn't help as much as you state, it's barely measurable when commenting out from my experiments (try it out!).
    • pkolaczk 12y ago
      C++ version is not "less functional". It is not functional at all. To make it functional you'd have to use immutable state.
• humanrebar 12y ago
  The Intel and GNU C++ compilers usually produce even faster code than the compiler used (Clang). Also, if it's business critical, you can do heavy calculations through GPUs or other custom hardware.
  • SoapSeller 12y ago
    Not for this example. On E5-2680 v2(Ivy Bridge): ./magic_forest_gcc 617 655 606 7.22s user 0.36s system 100% cpu 7.580 total ./magic_forest_icc 617 655 606 7.00s user 0.34s system 100% cpu 7.340 total ./magic_forest_clang 617 655 606 5.73s user 0.25s system 100% cpu 5.980 total gcc version 4.8.2 icc version 14.0.1 clang version 3.4 (On 3.14 powered arch linux) It's might be interesting to see what kind of optimisation clang does, but I currently don't have the time to look into it.
    • praseodym 12y ago
      And then there's the question of what compiler flags you used. Furthermore, one of the compilers could be really good at profile-guided optimisation (PGO), beating the others.
      • SoapSeller 12y ago
        I've used the same flags like the OP have suggested in the source header comment.
    • berkut 12y ago
      How big are the binaries? ICC inlines a lot more heavily, it's possible (I've seen it before) the code size has bloated, not fitting into the IC... Having said that, most of ICC's general gains over GCC and LLVM are due to the much faster maths libraries (even more so on Linux), and that doesn't look like that would be useful for these tests...
      • SoapSeller 12y ago
        Yep, ICC's output is much bigger: clang 29K gcc 36K icc 89K
• en4bz 12y ago
  One thing that I've yet to see mentioned is inlining. Almost all the functions/lambdas passed to STL functions in the code are likely inlined. This gives a huge performance boost and is one of the few cases where C++ is often faster than even C as calls through function pointers can be eliminated.
  • anon4 12y ago
    The JVM should, after enough iterations, inline all those calls as well.