Earlier quoted context omitted.
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).
Performance comparison of Functional C++ 11, Java 8, JavaScript and Wolfram
61–70 of 115 posts
Re: Performance comparison of Functional C++ 11, Java 8, JavaScript and Wolfram
#62Earlier quoted context omitted.
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.
> 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…
Re: Performance comparison of Functional C++ 11, Java 8, JavaScript and Wolfram
#63Earlier 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…
Re: Performance comparison of Functional C++ 11, Java 8, JavaScript and Wolfram
#64It is rather sad that none of the 49 comments (at this time of posting) have made a mention of the underlying math problem, which is super interesting, and instead focus on dubious speed metrics (dubious in the sense these metrics change with the chip/cache/RAM/compiler/lang/coding-style & aren't that relevant anyways, compared to the underlying problem) Lemme rephrase this rather interesting problem: There are 2055…
A minor nit to pick: the 1,448,575,636 number is not the number of buyouts. (It looks like the number of nodes in the evaluation graph.)
Spoiler: the answer is 111110110111_2. (edit: had the wrong answer)
Re: Performance comparison of Functional C++ 11, Java 8, JavaScript and Wolfram
#65Re: Performance comparison of Functional C++ 11, Java 8, JavaScript and Wolfram
#66It is rather sad that none of the 49 comments (at this time of posting) have made a mention of the underlying math problem, which is super interesting, and instead focus on dubious speed metrics (dubious in the sense these metrics change with the chip/cache/RAM/compiler/lang/coding-style & aren't that relevant anyways, compared to the underlying problem) Lemme rephrase this rather interesting problem: There are 2055…
1) In any of the transformations [(-,-,+),(-,+,-),(+,-,-)], the delta b/w numbers (s-b, s-z, b-z) changes by 0 or 2. What this tells us is that if the delta is odd to start, it will always be odd, if even always even.
2) Since the final state will involve only one type left standing (or else the stronger could eat the weaker), we know that the final counts will be two at 0, one at something >0. Since our losers end with an even delta (0), they must always have had an even delta. In the scenario you proposed, that's s and z (2055 - 2017 = 38). So b, bigcorps, is going to be our winner.
3) Now that we know who will win, we need to find the maximum possible number of bs remaining. Since each move reduces the total population by one, the maximum bs will be produced by the shortest sequence of moves that gets rid of all zs and ss.
4) As long as z>0 and s>0, our best move is to have z eat s, as it drops the population of z and s by 2. So our first sequence is to have all zs eat ss, leaving us with s = 38, b = 4023, z = 0.
5) When z = 0, our only possible move is b eats s, creating a z, which can then be eaten by an s to produce a b, thereby restoring b to its original count and lowering s by 2. After repeating this sequence 19 times to get rid of the 38 ss, we'll have s = 0, b = 4023, z = 0.
Ergo, maximal final state is 4023 bigcorps.
Re: Performance comparison of Functional C++ 11, Java 8, JavaScript and Wolfram
#67A 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?
Re: Performance comparison of Functional C++ 11, Java 8, JavaScript and Wolfram
#68Actually surprised Java lagged behind so far behind... It's usually the case that "Java is 95% as fast as CPP, but can be written with a fraction of the violence." Any real explanations?
Re: Performance comparison of Functional C++ 11, Java 8, JavaScript and Wolfram
#69It is rather sad that none of the 49 comments (at this time of posting) have made a mention of the underlying math problem, which is super interesting, and instead focus on dubious speed metrics (dubious in the sense these metrics change with the chip/cache/RAM/compiler/lang/coding-style & aren't that relevant anyways, compared to the underlying problem) Lemme rephrase this rather interesting problem: There are 2055…
I made some modifications (diverging further from the "functional" nature, if you could call it that) and as you can see it is much faster[0].
Output:
$ node new-magicForest.js 2017 2055 2006
total forests: 6128
{ goats: 0, wolves: 0, lions: 4023 }
total time: 20ms
[0] https://gist.github.com/chapel/1c038b2bf64b3037aaeaRe: Performance comparison of Functional C++ 11, Java 8, JavaScript and Wolfram
#70Neat 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.
http://unriskinsight.blogspot.co.at/2014/05/the-f-word-of-pr...