Live data from Hacker News

A comparison of programming languages in economics

marginalrevolution.com

81–83 of 83 posts

Re: A comparison of programming languages in economics

#81
post #72
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…

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. This is rather half-baked reasoning. The only ways I can think of to control for programmer skill or at least account for it is to 1.…

The closest to #3 available seems to be -- "Plat_Forms - The web development platform comparison"

https://www.plat-forms.org/

Re: A comparison of programming languages in economics

#82

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

Wouldn't that make the results arbitrary - nothing more than a reflection of the ignorance of the participants?

Re: A comparison of programming languages in economics

#83
post #74
post #68

Earlier quoted context omitted.

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.

JVM is impressive until closures are involved, in which case when inlining is not done (either because it cannot be or ever-changing heuristics are not met), you can drop back to virtual calls and performance suffers a great deal. Compare to C++ where closures can be used with virtually no penalty and aggressively optimized. Even C with its trick of passing an extra *void for environment comes out shining performance…

Actually, C++ has worse problems with this. Consider separate compilation and dynamic library loading. There is no way a static C++ compiler can inline accross dynamic module boundaries nor megamorphic call sites when the called function tree is not inlined completely up to the caller level. In rare cases, when it is, both Java and C++ do it now.

JVM inlining is unmatched by static compilers now and is going to only improve once techniques described in the Azul paper are used. Sure, JVM has a ton of other problems compared to C++, but inlining is not one of them.

BTW: I agree with the point that JVM optimizations are not enough and you often have to know what you're doing and optimize by hand appropriately.

Post reply on HN