Live data from Hacker News

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

unriskinsight.blogspot.com

61–70 of 115 posts

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

#61
post #38

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

Um no. It's a huge deal for heavy duty computational code, so much so that most performance oriented numeric libraries have extra code to workaround the case where restrict is not available..

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

#62
post #48
post #43

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

Java still lets you make a giant array and operate on that. For high speed numerics programming you do that in every language: FORTRAN, C, Java, etc. At that point comes down to how much information the compiler and you can share: restricted pointers, use assembler kernels, etc.

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

#63
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…

Whatever the claims about Fortran, I would say that 3) is definitely not applicable here (two implementations provided, 2) is laughable (some people used to argue Fortran was the easiest to optimize) and 1) is true, but not in a way that would have a significant impact on this benchmark. Fortran compilers have been optimized over the years pretty extensively, and really of late the only reason to have a Fortran compiler is for efficient numerical computation, so that is something Fortran compiler writers have focused on.

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

#64
post #53

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

It is a really cool math problem, and we should be using math to solve it! This problem took me 30 minutes to solve without programming and so I'm only a few minutes off Fortran. (I scale well too since I can now do it in constant time - fine log time if we count reading the input.)

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

#66
post #53

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

Let s = startups, b = bigcorps, z = zombies

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

#67

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?

I've seen this on other blogs too hosted by Blogger/Blogspot. I'm pretty sure it's their doing, not the blog owner himself.

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

#68

Actually 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?

I've never heard anybody say that Java is that fast. It can be in very specific situations. Actually 2 - 3 times as fast as C++ is pretty awesome, especially since that is hardly low level Java, rather quite abstract. I suspect low level Java could get it down to a flat 2x in this case. For a huge range of uses 2x as fast is effectively as fast as C, especially since taking advantage of multicore / parallelized operations is significantly easier (in a cross platform manner) than it is in C/C++.

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

#69
post #53

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

The code is very inefficient to say the least.

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/1c038b2bf64b3037aaea

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

#70
post #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.

That is if we accept the assumption that this was well written modern fortran code. Since they don't actually show the fortran it is hard to say. I looked through the referenced posts and all of those are using fortran 77. Furthermore it depends very very heavily on compiler optimizations. Yet another thing they made no mention of.

http://unriskinsight.blogspot.co.at/2014/05/the-f-word-of-pr...

Post reply on HN