Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Performance comparison of Functional C++ 11, Java 8, JavaScript and Wolfram

unriskinsight.blogspot.com

Post reply on HN
Print view View original

31–40 of 115 posts

Re: Performance comparison of Functional C++ 11, Java 8, JavaScript and Wolfram

#31

Post by kbenson »

cbsmith wrote: post #27
georgemcbay wrote: post #20

Earlier quoted context omitted.

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 "According to Sun Microsystems, the Hotspot virtual machine, Sun's next-generation Java virtual machine (JVM), promises to make Java "as fast as C++.""

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 diff…

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.

Re: Performance comparison of Functional C++ 11, Java 8, JavaScript and Wolfram

#32

Post by SoapSeller »

humanrebar wrote: post #15
zik wrote: post #2

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 binaries.

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.

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.

Re: Performance comparison of Functional C++ 11, Java 8, JavaScript and Wolfram

#33

Post by mtdewcmu »

cbsmith wrote: post #29
alayne wrote: post #11

Earlier quoted context omitted.

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.

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.

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.

Re: Performance comparison of Functional C++ 11, Java 8, JavaScript and Wolfram

#35

Post by gsnedders »

mtdewcmu wrote: post #8
zik wrote: post #2

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 binaries.

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.…

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.

Re: Performance comparison of Functional C++ 11, Java 8, JavaScript and Wolfram

#36

Post by en4bz »

zik wrote: post #2

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 binaries.

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.

Re: Performance comparison of Functional C++ 11, Java 8, JavaScript and Wolfram

#38

Post by tbirdz »

mtdewcmu wrote: post #30
cbsmith wrote: post #26

Earlier quoted context omitted.

> 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.

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 n…

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++.

Re: Performance comparison of Functional C++ 11, Java 8, JavaScript and Wolfram

#40

Post by praseodym »

tbirdz wrote: post #38
mtdewcmu wrote: post #30

Earlier quoted context omitted.

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 n…

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++.

But then again, things like the restrict keyword don't matter that much, except when using specialised compilers (e.g. for DSP chips).
Post reply on HN