Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A comparison of programming languages in economics

marginalrevolution.com

Post reply on HN
Print view View original

31–40 of 83 posts

Re: A comparison of programming languages in economics

#31

Post by adrusi »

dodders wrote: post #15
MrBuddyCasino wrote: post #13

In case anyone missed the Java results, I do think it is worth mentioning that it is very competitive: "Our fourth result is that Java imposes a speed penalty of 110 to 169 percent. Given the similarity between Java and C++ syntax, there does not seem to be an obvious advantage for choosing Java unless portability across platforms or the wide availability of Java programmers is an important factor."

In my professional life I have rarely (if ever?) seen a language chosen on the basis of it's syntax.

It's true, most good programmers won't choose a language based on just syntax. And even though most economists aren't good programmers (in my experience), they're still smart people who can see past the syntax.

The paper is probably misusing the term syntax though. C++ and java really are quite similar in many ways, far beyond just syntax, java just letting the programmer forget about some annoying things like memory management and portability. If most of what they're doing in the language is numeric analysis, then there probably isn't much of a difference at all, and they will probably get slightly better performance from C++.

Re: A comparison of programming languages in economics

#32

Post by briandh »

minimax wrote: post #3

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

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

Re: A comparison of programming languages in economics

#34

Post by adrusi »

It's important to note that the available libraries for each language varies a lot, and the best performing ones are proprietary for the most part. Fortran, for example, has a set of proprietary libraries that many employers buy that have been continually optimized for nearly 50 years. Both C and Python can readily bind to Fortran libraries, but for other languages like R, Matlab, Mathematica, etc. this is a major disadvantage.

Re: A comparison of programming languages in economics

#35

Post by bachmeier »

adrusi wrote: post #34

It's important to note that the available libraries for each language varies a lot, and the best performing ones are proprietary for the most part. Fortran, for example, has a set of proprietary libraries that many employers buy that have been continually optimized for nearly 50 years. Both C and Python can readily bind to Fortran libraries, but for other languages like R, Matlab, Mathematica, etc. this is a major di…

Not only is it easy to call Fortran functions from R, the inline package actually allows you to embed Fortran functions inside your R program.

Re: A comparison of programming languages in economics

#36

Post by chuto »

bradfordarner wrote: post #6
minimax wrote: post #3

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

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…

It is also unfortunate that several of the language developers and related dev communities have come out against compilers (python and jython in particular). This is the (religious) downside to open source fundamentalism.

Re: A comparison of programming languages in economics

#37

Post by rlvesco7 »

minimax wrote: post #3

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

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.

Re: A comparison of programming languages in economics

#39

Post by georgewfraser »

There are two glaring problems with this paper:

1. The algorithm is just a bunch of arrays and loops in one giant block. This is the easiest possible case for compilers that optimize through specialization. Even a bad specializing compiler will be good at this but will blow up when faced with a big piece of code with lots of functions and data structures.

2. The runtimes are only ~2s, which is not long enough for the JIT-compiled languages to "warm up". I suspect Java in particular would have had the exact same runtime after warming up, because in an easy example like this Hotspot will generate the exact same instructions as the C program.

EDIT: I stand corrected. I downloaded his examples off Github and ran them the same way as the paper. I get 1.87s for C, and for Java... also exactly 1.87s.

Re: A comparison of programming languages in economics

#40

Post by Alupis »

briandh wrote: post #32
minimax wrote: post #3

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

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

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.

Post reply on HN