Live data from Hacker News

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

unriskinsight.blogspot.com

1–10 of 115 posts

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

#4
Neat results, and a neat comparison of the languages.

I'm a bit curious how an asm.js port (via whatever means. maybe c++ -> emscripten?) ends up performing.

edit: heh.

>Also note that FORTRAN is not included in the list [of relative speedups], because no sane person would switch to FORTRAN from another programming language voluntarily.

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

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

Compilation method isn't what's going on here. Static type systems are, as explained in the article.

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

#7
Few major points:

Using sort to filter duplicates is horribly worse compared to hashing (javascript for instance). Java version has rather poor impl, it's interesting to see the GC+allocation cost and the GC type used. C++ version does not use really use func. prog in find_stable_forests and meal...

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

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

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

#9
post #4

Neat results, and a neat comparison of the languages. I'm a bit curious how an asm.js port (via whatever means. maybe c++ -> emscripten?) ends up performing. edit: heh. > Also note that FORTRAN is not included in the list [of relative speedups], because no sane person would switch to FORTRAN from another programming language voluntarily.

It's embarrassing that Fortran gets beat by Java.

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

#10
post #8
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.…

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?

Post reply on HN