A message to the blog owner: get rid of that swipe to go forward/backward between posts when viewing on mobile. It looks good, but it is functionally frustrating. Why would a user expect different swipe behaviour in one direction to another?
Performance comparison of Functional C++ 11, Java 8, JavaScript and Wolfram
21–30 of 115 posts
Re: Performance comparison of Functional C++ 11, Java 8, JavaScript and Wolfram
#22Earlier quoted context omitted.
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.…
Maybe 5 years ago, I wrote a mancala game in C++ and Java. The minmax part was maybe 10% slower in Java.
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.
Re: Performance comparison of Functional C++ 11, Java 8, JavaScript and Wolfram
#23Earlier quoted context omitted.
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?
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 wonder how well modern JVMs compare to C++ compilers from 1998?
Re: Performance comparison of Functional C++ 11, Java 8, JavaScript and Wolfram
#24Few 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...
Using sort to filter duplicates is horribly worse compared to hashing (javascript for instance).
Is this really true? A sort plus a linear scan has very low constant time factors, good cache locality (depending on the sorting algorithm used), and no need to allocate if you're sorting in place. I've seen good results using sort to filter duplicates in my own performance-sensitive code. Are you saying this technique is "horribly worse" based on your experience or intuition?
Re: Performance comparison of Functional C++ 11, Java 8, JavaScript and Wolfram
#25Earlier quoted context omitted.
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?
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++.""
There's nothing wrong with trying to sell your product. But I hope Sun's salesmanship doesn't continue to deceive people.
Re: Performance comparison of Functional C++ 11, Java 8, JavaScript and Wolfram
#26It'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.…
> 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.
Re: Performance comparison of Functional C++ 11, Java 8, JavaScript and Wolfram
#27Earlier quoted context omitted.
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?
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 differences between it and "as fast as" are trivial enough that a number of HFT systems, for example, are written in Java.
Re: Performance comparison of Functional C++ 11, Java 8, JavaScript and Wolfram
#28See also: https://news.ycombinator.com/item?id=7850394 (Code length comparison for several languages)
Re: Performance comparison of Functional C++ 11, Java 8, JavaScript and Wolfram
#29Earlier quoted context omitted.
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'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.
Re: Performance comparison of Functional C++ 11, Java 8, JavaScript and Wolfram
#30Earlier quoted context omitted.
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.…
> 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 no one uses it anymore.
I don't know which it might be.