6 ms·

Their code is on github [1]. I am a C++ programmer so I'm happy that C++ came out on top, but the comparison is obviously flawed (as these sorts of comparisons

by minimax 12y ago

Their code is on github [1]. I am a C++ programmer so I'm happy that C++ came out on top, but the comparison is obviously flawed (as these sorts of comparisons always are). The problem is that the implementers don't have the same level of skill in each language and who knows how much time they spent analyzing and refining each version. See Russ Cox's response [2] to a Google paper [3] of a similar nature comparing C++, Go, Java, Scala for an example of a similar boondoggle. The R code, for instance, is obviously unidiomatic. If you have a four levels deep nested loop in R, you're doing it wrong, and it's taking every ounce of willpower to keep from spending the rest of the afternoon trying to fix up their code and make it faster. 1. https://github.com/jesusfv/Comparison-Programming-Languages-Economics https://github.com/jesusfv/Comparison-Programming-Languages-... 2. http://blog.golang.org/profiling-go-programs http://blog.golang.org/profiling-go-programs 3. http://research.google.com/pubs/pub37122.html http://research.google.com/pubs/pub37122.html

danielweber 12y ago
I'm hoping that -- and will be pleased by the irony if -- the HN discussion has less language war than the MR discussion. It's worth knowing, for economists, how well economists can write code in different languages. But I'm sure I, too, would write better C++ than R, since I've not written any R at all. They would need to ask economists skilled in each language to write the code to get a better answer, and there would still be a lot of noise in the signal. EDIT last sentence was gibbgersh
bradfordarner 12y ago
It is unfortunate that the authors of this paper didn't reach out to experts in each programming language in order to write high-quality code against which they could have run the analysis. This seems like the perfect use-case for open-source: academic study, subject-matter experts in one area who are stepping outside their areas of expertise and an interesting subject matter. They should have crowd-sourced the code for this study with a Top Coder-like contest.
- ViralBShah 12y ago
  I don't know about other languages, but the authors did reach out to us to sort out performance issues with the Julia code.
  - bradfordarner 12y ago
    That is very good to know. That reassures me a little. I was really impressed with the speed difference they noted between Python and R and the fact that Numba wasn't too much slower than C++ implementations. However, given the state of the R code I became wary of accepting the benchmarks at face value. I haven't made the jump from R to Python for statistical applications yet. So, this article gave me something to think about. In terms of programmer happiness, I'm willing to live with a little slower performance in Python and not have to spend hours in C++.
    - Fede_V 12y ago
      I've used Numba to speed up some tight numerical computations written on NumPy arrays and it's incredibly good - about as fast as rewriting it from scratch in Cython, but much, much faster. The flipside is that it only really results in a speed up for pure numerical code - if you have to use any Python objects, then you lose everything.
- k2enemy 12y ago
  From the paper... Second, to make the comparison as unbiased as possible, we coded the same algorithm in each language without adapting it to the peculiarities of each language (which could reflect more about our knowledge of each language than of its objective virtues). They have invited others to fork the code on github and write the fastest possible for each language.
  - bradfordarner 12y ago
    Thank you for the note. I hadn't visited the github yet. I will be interested to see whether people can whittle down the respective benchmarks.
ViralBShah 12y ago
The stochastic growth model, which is the workhorse of modern economics, cannot be easily vectorized, and usually requires tight inner loops to get good performance, or rewrite the computational kernels in C. Codes such as Dynare (http://www.dynare.org http://www.dynare.org) do exactly that. In my opinion, this is where Julia shines - it provides high performance in a dynamic language, much at the level of R or MATLAB. Then again, being a co-creator of Julia, I am probably biased, but this is exactly the kind of thing that motivated work on Julia in the first place.
- minimax 12y ago
  The two things I like about Julia are actually using it and all the smart people I have met who are also using it. It's awesome. After playing with this particular problem a bit, I do see how it is a pathological case for R due to the recursive nature of the value function. I still think I could do better than 500x slower than C++.
- bachmeier 12y ago
  The stochastic growth model is the workhorse of a narrow subfield of economics. It is not in any way representative of the research we do. Further, you will not find any examples that are better suited to compiled languages or less suited to using R than the one in this paper. To my knowledge, value function iteration isn't even used much in this area of research, so the claim that the stochastic growth model is a "workhorse" is a bit misleading - the stochastic growth model gets used, but it is not solved very often using the methodology in this paper.
- c0g 12y ago
  Hi Viral, do you have an intuition for why Numba would be faster than Julia here? It appears Julia spends a lot of time calculating the log on line 71.
  - ihnorton 12y ago
    (not Viral, but) yes - log was the first thing that came up when this paper was discussed on the Julia mailing list. Julia's openlibm is intended to provide cross-platform accuracy and consistency, but the log function turned out to be slower than log in the system libm used by C++ and Python. The other big reason that Numba was faster was GC performance. There is an outstanding pull request adding incremental GC to Julia, which should help when it is fully integrated, and several other improvements are planned.
cs702 12y ago
I almost gasped when I saw that their R code[1] does the bulk of its computations inside a while(...for(...for(...for(...if(...){...}else{...})))) block, instead of using functionals like apply and 'vectorized' operations like ifelse. If this criticism seems harsh, compare the authors' R code to Hadley Wickham's advice at http://adv-r.had.co.nz/Profiling.html http://adv-r.had.co.nz/Profiling.html -- or just search Google for "speed-up loops in R". -- [1] https://github.com/jesusfv/Comparison-Programming-Languages-Economics/blob/master/RBC_R.R https://github.com/jesusfv/Comparison-Programming-Languages-...
- collyw 12y ago
  Many of the bioinformaticains I know use R. Not knowing how to use it properly wouldn't surprise me in the slightest. I struggle to get some of them to indent their Perl code.
briandh 12y ago
>The problem is that the implementers don't have the same level of skill in each language and who knows how much time they spent analyzing and refining each version One of they authors addresses this in the comments on the OP: > As we explain in the paper, this was a “design” parameter. We did not want to “adapt” the algorithm to each language to improve speed, because it will open the door to too many “uncontrolled variables” (how good a programmer in that language you are and so on). The only partial exception was with Mathematica for reasons explained in the paper. > Yes, we know how to code better and prettier R code with the plyr package and related tools. Again, that was not what we wanted to do in this exercise. But we will be thrilled to see alternative versions on github. That is why we posted all our code there. > My personal guess is that, given how large our capital grid is, plyr will go less far than some people would have forecast, but I’d be happy to be proven wrong. And if zissou is correct below in his assertion that the "vast majority of economists are horrible programmers", a comparison of what a naive user would write may be the most useful.
- Alupis 12y ago
  The "study" does not account for nuances in each language. JIT'ed java code will run at native C performance... because it essentially is native C once it's been JIT'ed. The tests did not account for JVM warm-up time, nor allow the code to become "hot" before running their tests. They also executed their test code on poorly performing operating systems not designed to execute high performance code, ie. they ran their tests on consumer desktop general purpose operating systems instead of a more specialized system designed for the task... or at the very least a more specialized OS such as a flavor of BSD or Linux without the desktop and other generalized packages. I don't really consider this a well done test, and the results are only surface-level... certainly nothing you should base a serious decision on.
  - taeric 12y ago
    JIT'ed Java code is lacking a major facility that truly performant native code has, and that is cache locality. That is, it isn't enough that the code to perform the algorithm is "well tuned" if the data structures are not. (Well, unless I am just wrong on the feats that JIT'ed code can perform nowdays.)
rlvesco7 12y ago
It would have been nice to see R with c++. Using the Rcpp package you can write inline c++ for the heavy loops like a boss.
sveme 12y ago
Given that their code is on github and many people criticized the unidiomatic nature of their code, wouldn't it make sense to set up a competition to improve the code? Everyone can submit pull requests with their improved codes and the authors should simply rerun the codes on a standard machine to get a benchmark. Obviously, a couple of rules should apply: 1. when you improve the code, do not move any elements outside the benchmarked language, i.e., don't use mex files in Matlab, c++ in R etc. 2. maybe create two or three different versions of your code - single processor, multiple cpus, gpu and run it on a single machine with a predefined set up. This will remove at least some of the criticism thrown at the economists and has an additional benefit: researchers trying to find the best-suited language for their problem can not only use speed but also expressiveness, aesthetics, code length, boilerplate and ease of use to guide their decision.
- igouy 12y ago
  http://benchmarksgame.alioth.debian.org/ http://benchmarksgame.alioth.debian.org/

by minimax 12y ago

danielweber 12y ago

I'm hoping that -- and will be pleased by the irony if -- the HN discussion has less language war than the MR discussion. It's worth knowing, for economists, how well economists can write code in different languages. But I'm sure I, too, would write better C++ than R, since I've not written any R at all. They would need to ask economists skilled in each language to write the code to get a better answer, and there would still be a lot of noise in the signal. EDIT last sentence was gibbgersh

bradfordarner 12y ago

It is unfortunate that the authors of this paper didn't reach out to experts in each programming language in order to write high-quality code against which they could have run the analysis. This seems like the perfect use-case for open-source: academic study, subject-matter experts in one area who are stepping outside their areas of expertise and an interesting subject matter. They should have crowd-sourced the code for this study with a Top Coder-like contest.

ViralBShah 12y ago
I don't know about other languages, but the authors did reach out to us to sort out performance issues with the Julia code.
- bradfordarner 12y ago
  That is very good to know. That reassures me a little. I was really impressed with the speed difference they noted between Python and R and the fact that Numba wasn't too much slower than C++ implementations. However, given the state of the R code I became wary of accepting the benchmarks at face value. I haven't made the jump from R to Python for statistical applications yet. So, this article gave me something to think about. In terms of programmer happiness, I'm willing to live with a little slower performance in Python and not have to spend hours in C++.
  - Fede_V 12y ago
    I've used Numba to speed up some tight numerical computations written on NumPy arrays and it's incredibly good - about as fast as rewriting it from scratch in Cython, but much, much faster. The flipside is that it only really results in a speed up for pure numerical code - if you have to use any Python objects, then you lose everything.
k2enemy 12y ago
From the paper... Second, to make the comparison as unbiased as possible, we coded the same algorithm in each language without adapting it to the peculiarities of each language (which could reflect more about our knowledge of each language than of its objective virtues). They have invited others to fork the code on github and write the fastest possible for each language.
- bradfordarner 12y ago
  Thank you for the note. I hadn't visited the github yet. I will be interested to see whether people can whittle down the respective benchmarks.

ViralBShah 12y ago

The stochastic growth model, which is the workhorse of modern economics, cannot be easily vectorized, and usually requires tight inner loops to get good performance, or rewrite the computational kernels in C. Codes such as Dynare (http://www.dynare.org http://www.dynare.org) do exactly that. In my opinion, this is where Julia shines - it provides high performance in a dynamic language, much at the level of R or MATLAB. Then again, being a co-creator of Julia, I am probably biased, but this is exactly the kind of thing that motivated work on Julia in the first place.

minimax 12y ago
The two things I like about Julia are actually using it and all the smart people I have met who are also using it. It's awesome. After playing with this particular problem a bit, I do see how it is a pathological case for R due to the recursive nature of the value function. I still think I could do better than 500x slower than C++.
bachmeier 12y ago
The stochastic growth model is the workhorse of a narrow subfield of economics. It is not in any way representative of the research we do. Further, you will not find any examples that are better suited to compiled languages or less suited to using R than the one in this paper. To my knowledge, value function iteration isn't even used much in this area of research, so the claim that the stochastic growth model is a "workhorse" is a bit misleading - the stochastic growth model gets used, but it is not solved very often using the methodology in this paper.
c0g 12y ago
Hi Viral, do you have an intuition for why Numba would be faster than Julia here? It appears Julia spends a lot of time calculating the log on line 71.
- ihnorton 12y ago
  (not Viral, but) yes - log was the first thing that came up when this paper was discussed on the Julia mailing list. Julia's openlibm is intended to provide cross-platform accuracy and consistency, but the log function turned out to be slower than log in the system libm used by C++ and Python. The other big reason that Numba was faster was GC performance. There is an outstanding pull request adding incremental GC to Julia, which should help when it is fully integrated, and several other improvements are planned.

cs702 12y ago

I almost gasped when I saw that their R code[1] does the bulk of its computations inside a while(...for(...for(...for(...if(...){...}else{...})))) block, instead of using functionals like apply and 'vectorized' operations like ifelse. If this criticism seems harsh, compare the authors' R code to Hadley Wickham's advice at http://adv-r.had.co.nz/Profiling.html http://adv-r.had.co.nz/Profiling.html -- or just search Google for "speed-up loops in R". -- [1] https://github.com/jesusfv/Comparison-Programming-Languages-Economics/blob/master/RBC_R.R https://github.com/jesusfv/Comparison-Programming-Languages-...

collyw 12y ago
Many of the bioinformaticains I know use R. Not knowing how to use it properly wouldn't surprise me in the slightest. I struggle to get some of them to indent their Perl code.

briandh 12y ago

>The problem is that the implementers don't have the same level of skill in each language and who knows how much time they spent analyzing and refining each version One of they authors addresses this in the comments on the OP: > As we explain in the paper, this was a “design” parameter. We did not want to “adapt” the algorithm to each language to improve speed, because it will open the door to too many “uncontrolled variables” (how good a programmer in that language you are and so on). The only partial exception was with Mathematica for reasons explained in the paper. > Yes, we know how to code better and prettier R code with the plyr package and related tools. Again, that was not what we wanted to do in this exercise. But we will be thrilled to see alternative versions on github. That is why we posted all our code there. > My personal guess is that, given how large our capital grid is, plyr will go less far than some people would have forecast, but I’d be happy to be proven wrong. And if zissou is correct below in his assertion that the "vast majority of economists are horrible programmers", a comparison of what a naive user would write may be the most useful.

Alupis 12y ago
The "study" does not account for nuances in each language. JIT'ed java code will run at native C performance... because it essentially is native C once it's been JIT'ed. The tests did not account for JVM warm-up time, nor allow the code to become "hot" before running their tests. They also executed their test code on poorly performing operating systems not designed to execute high performance code, ie. they ran their tests on consumer desktop general purpose operating systems instead of a more specialized system designed for the task... or at the very least a more specialized OS such as a flavor of BSD or Linux without the desktop and other generalized packages. I don't really consider this a well done test, and the results are only surface-level... certainly nothing you should base a serious decision on.
- taeric 12y ago
  JIT'ed Java code is lacking a major facility that truly performant native code has, and that is cache locality. That is, it isn't enough that the code to perform the algorithm is "well tuned" if the data structures are not. (Well, unless I am just wrong on the feats that JIT'ed code can perform nowdays.)

rlvesco7 12y ago

It would have been nice to see R with c++. Using the Rcpp package you can write inline c++ for the heavy loops like a boss.

sveme 12y ago

Given that their code is on github and many people criticized the unidiomatic nature of their code, wouldn't it make sense to set up a competition to improve the code? Everyone can submit pull requests with their improved codes and the authors should simply rerun the codes on a standard machine to get a benchmark. Obviously, a couple of rules should apply: 1. when you improve the code, do not move any elements outside the benchmarked language, i.e., don't use mex files in Matlab, c++ in R etc. 2. maybe create two or three different versions of your code - single processor, multiple cpus, gpu and run it on a single machine with a predefined set up. This will remove at least some of the criticism thrown at the economists and has an additional benefit: researchers trying to find the best-suited language for their problem can not only use speed but also expressiveness, aesthetics, code length, boilerplate and ease of use to guide their decision.

igouy 12y ago
http://benchmarksgame.alioth.debian.org/ http://benchmarksgame.alioth.debian.org/