I don't think although all these languages have some functional characteristics that they should be called functional languages. It seems like the OP was more concerned with getting the results he wanted rather than answering the “Can a functional language do this as well?” question.
Performance comparison of Functional C++ 11, Java 8, JavaScript and Wolfram
81–90 of 115 posts
Re: Performance comparison of Functional C++ 11, Java 8, JavaScript and Wolfram
#82Hmm... it doesn't mention anything about the used VM settings.
System has 8gb ram. But as i remember java vm is restricted in its use of ram as is NodeJs ( i guess this test was performed in node). To use full 8gb ram you would have to run multiple nodejs instances? am i wrong?
Re: Performance comparison of Functional C++ 11, Java 8, JavaScript and Wolfram
#83Earlier quoted context omitted.
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 optimisatio…
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...
Re: Performance comparison of Functional C++ 11, Java 8, JavaScript and Wolfram
#84what did you use for Javascript??...nodejs??
How each program was compiled/run is documented in the source: http://www.unisoftwareplus.com/download/blog/2014-06/magicFo...
Re: Performance comparison of Functional C++ 11, Java 8, JavaScript and Wolfram
#85Earlier quoted context omitted.
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…
Just to add to the discussion: you're likely correct, based on this SO question: http://stackoverflow.com/questions/11227809/why-is-processin... It will likely get faster the more duplicates you have, as it allows the CPU to predict a branch more reliably several times before being wrong and having to re-do some of its prediction stuff. (note that I'm not experienced with optimizing stuff, dealing with cache optimiza…
That question (and answer) is probably not relevant here. The important thing is likely cache locality, not branch prediction (as the test case is very different in that question, amplifying branch misprediction issues, which won't be the issue here).
Re: Performance comparison of Functional C++ 11, Java 8, JavaScript and Wolfram
#86I was curious how a non-functional version would fare, so I wrote one in Nimrod and it's a lot faster than the functional C++: https://gist.github.com/def-/8187448ea7a5c8da8265
Goats Wolves Lions C++11 Nimrod
17 55 6 0.00 0.00
117 155 106 0.17 0.01
217 255 206 0.75 0.01
317 355 306 2.16 0.01
417 455 406 5.28 0.01
517 555 506 10.75 0.01
617 655 606 19.15 0.02
717 755 706 31.58 0.02
817 855 806 46.52 0.02
917 955 906 67.94 0.02
1017 1055 1006 93.75 0.02
2017 2055 2006 731.42 0.04Re: Performance comparison of Functional C++ 11, Java 8, JavaScript and Wolfram
#87Earlier quoted context omitted.
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 optimisatio…
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...
Yep, ICC's output is much bigger:
clang 29K
gcc 36K
icc 89KRe: Performance comparison of Functional C++ 11, Java 8, JavaScript and Wolfram
#88Earlier 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.…
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.
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.
Re: Performance comparison of Functional C++ 11, Java 8, JavaScript and Wolfram
#89But C++11 solution is not functional. It uses state variables: look at the while loop, it updates variable. Look at the next_forests.reserve, std::back_inserter. These are not clear functional constructs. Of course it is possible to model memory state with the monads :) but... The C++ code is quite different from other codes. So i was surprised by Java which is only 3 times slower than C++ while running a much less e…
Glad someone pointed that out. It is cheating. It is doing a lot of state transformations like in-place sorting / filtering. I'd like to see some real C++ functional code here, using immutable data structures, not an imperative program using lambdas. I guess it would be both much harder to write (C++ is not really a functional language) and much slower, because dynamic memory allocation in C++ is more costly than in Java.
Re: Performance comparison of Functional C++ 11, Java 8, JavaScript and Wolfram
#90Earlier quoted context omitted.
The main issue is that C version is hardly functional programming: stuff like array 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.
I don't see how the use of std::array 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!).
C++ version is not "less functional". It is not functional at all. To make it functional you'd have to use immutable state.