Live data from Hacker News

A comparison of programming languages in economics

marginalrevolution.com

61–70 of 83 posts

Re: A comparison of programming languages in economics

#61
post #47

Earlier quoted context omitted.

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

While I agree Java makes writing cache-friendly code much harder than C, it is no-way impossible. Nor is any C or C++ code implicitly cache-friendly. Generally, in both cases you must know what you're doing. I also hope some of those problems are going to be addressed in Java 9.

Fair enough. My point was supposed to be more limited, saying that a JIT'ed solution is not a cure all for performance considerations. Sure, it is great that there is a JIT compiler helping out. It just is not necessarily enough on its own to even the performance gap between native and not.

Re: A comparison of programming languages in economics

#62
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 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 ) 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…

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.

Re: A comparison of programming languages in economics

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

That would answer the interesting question 'which language gives the fastest programs in the hands of someone who is an expert in that language?'

In fairness to the authors, though, it seems to me they were asking the equally interesting and rather different question 'which language gives the fastest programs in the hands of someone who is an expert in something other than programming?'

Re: A comparison of programming languages in economics

#64

Earlier quoted context omitted.

"The vast majority of economists are horrible programmers, however most know how to script in at least 1 language, and a small number of them are actually really good at scripting. An extremely small number of economists know they're way around at least 1 entire general purpose programming language." As an economist whose hobby is the study of programming languages, you can imagine the frustration that I feel. What I…

I'm sorry, but that it's a wasted emotion. Economists are not software developers. They do the minimal they need and nothing more. It's like complaining that a masseur has poor baking skills. Get over it! It's a support tool for them and until they demand that you take their code as a perfect example, developed have no need to complain.

[deleted]

Re: A comparison of programming languages in economics

#65
post #62

Earlier quoted context omitted.

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

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.

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

Re: A comparison of programming languages in economics

#66
post #14

Earlier quoted context omitted.

Hey, that's really neat. I'm doing a post-masters right now in energy economics and have been transitioning into using python for everything (from previously using Matlab or whatever was available), but I'm eyeing an economics PhD down the line. You have any advice/opinions on economics PhDs?

Do you have any specific questions? I teach in a PhD-granting department and do research in energy economics. (I'm an associate editor of one of the energy field journals.)

Huh, some of your papers sound like ideas I sketched out in my commonplace book (particularly the ones on oil prices in the context of the larger economy), looks like I'm a few years behind.

I guess my biggest concern is the viability of pursuing a PhD in economics without having a previous degree in econ. I have a BS and MS in environmental science and an MPA in energy policy/economics. I think I have stronger scientific chops than many economists, but I don't know how valuable that actually is.

Also, it seems to me that the general market for energy economists is very strong, and will remain that way for quite some time. Do you think that's accurate?

I love plowing through data and developing methods and analysis to try and draw out relationships and show why things are what they are. I know that sounds incredibly vague, but as far as I can tell economics is the field that most closely aligns with this in the context of energy and the environment.

Re: A comparison of programming languages in economics

#67
post #60
post #58

Earlier quoted context omitted.

>JIT'ed java code will run at native C performance... because it essentially is native C once it's been JIT'ed No way. It may be native C, but it's not native C you've hand-coded yourself.

C doesn't enter into it, any way you look at it. Unless you are using some obscure Java -> C compiler.

No, the optimizing compiler inside the JVM does produce a lot of native code for your system... c/assembler. It just has to discover hot spots then JIT them.

Re: A comparison of programming languages in economics

#68
post #61

Earlier quoted context omitted.

While I agree Java makes writing cache-friendly code much harder than C, it is no-way impossible. Nor is any C or C++ code implicitly cache-friendly. Generally, in both cases you must know what you're doing. I also hope some of those problems are going to be addressed in Java 9.

Fair enough. My point was supposed to be more limited, saying that a JIT'ed solution is not a cure all for performance considerations. Sure, it is great that there is a JIT compiler helping out. It just is not necessarily enough on its own to even the performance gap between native and not.

It is enough. You can perf test the same non-trivial program (such as a biz application) in C and Java, and given you allow the JVM to warm up, discover hot spots, and JIT your code... they will run just about the same performance level... every time. The JVM is impressive.

Re: A comparison of programming languages in economics

#69
post #32

Earlier quoted context omitted.

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

> 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. Sure, b…

Which language should I learn to use better? is probably a useful question to answer.

Re: A comparison of programming languages in economics

#70

Earlier quoted context omitted.

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…

That would answer the interesting question 'which language gives the fastest programs in the hands of someone who is an expert in that language?' In fairness to the authors, though, it seems to me they were asking the equally interesting and rather different question 'which language gives the fastest programs in the hands of someone who is an expert in something other than programming?'

http://benchmarksgame.alioth.debian.org/u64q/which-programs-...
Post reply on HN