

A Comparison of Programming Languages in Economics [pdf] - todd8
http://economics.sas.upenn.edu/~jesusfv/comparison_languages.pdf

======
Hermel
As having both, an economics and computer science background, I often feel
like economists focus on the wrong metrics when evaluating programming
languages.

The importance of raw computing speed of a programming language pales in
comparison with the importance of the applied methods, as well as the time
saved in development. For example, while a speed-up by a factor of two sounds
good on paper, the choice of search strategy in a constrained optimization
problem can change the running time by several orders of magnitude. I am
currently working on a model where the seemingly unimportant choice of price
normalization (i.e. which price in the model is set to 1.0 to determine the
price level) can make a difference between 2 seconds or 200 seconds of
computation time.

------
oelang
Meh, they dismiss java & pypy very quickly but they don't understand that
these languages require warm-up. If you benchmark runs in less than 2 seconds
half of the time measured is starting the runtime, profiling & compiling code.
I think that interesting computational problems in economics have a much
longer running time.

For this kind of algorithm, basically working with arrays of doubles, java
should be within 20% of c++ and normally it is just as fast.

~~~
east2west
Does Java have any way of auto vectorization? On modern CPUs SIMD can speed up
numerical computation several times easily. However auto vectorization is hard
in general, so compilers don't necessarily do a good job and manually
optimized code is common. C++ has TMP and libraries such as Eigen use TMP to
provide a nice interface to SIMD optimized code. I don't know whether Java has
equivalent of compiler intrinsics for SIMD instructions, without which Java
code would be far slower for many numerical computation. I believe C# has
plans to add an abstraction for SIMD and Mono can already emit SIMD
instructions.

~~~
oelang
Intel recently contributed improved auto-vectorisation for artithmetic to the
hotspot compiler. Auto-vectorisation of move instructions has been in hotspot
for a few years.

------
k2enemy
[https://news.ycombinator.com/item?id=7978410](https://news.ycombinator.com/item?id=7978410)

Lots of discussion from a year ago.

------
pvitz
I would be happy to use languages like J/K or Julia for our actuarial
projection simulations instead of C++. However, despite quicker development
times, a factor of 2 in the runtime for our stochastic projections would be
terrible. Has anyone experience with those languages in an HPC environment and
can compare it to a C++ implementation?

~~~
scottlocklin
Dang, someone wanting to replace C++ with J... I'd love to say you could do
this, since I am a big fan of J, but if you need to squeeze the last bit of
efficiency out of a machine on a problem that can't be parallelized, C++ is
probably a pretty good idea. If the "expensive in write time" logic isn't
expensive in calculation time, you could wrap the expensive pieces in some
verbs which call out to C.

I'm often surprised though; a naive implementation of wavelets in J was quite
comparable in runtime performance to a naive implementation of wavelets in C.

------
pella
github: [https://github.com/jesusfv/Comparison-Programming-
Languages-...](https://github.com/jesusfv/Comparison-Programming-Languages-
Economics)

------
oelang
"Java's issues with floating point arithmetic in high-performance scientific
computation"

Can someone explain this?

~~~
Hermel
Unlike C++, Java ensures that floating point calculations always yield the
exact same result, regardless of the underlying platform. This can degrate
performance.

I am not sure if they meant that thought, in my opinion this is an advantage
of Java.

~~~
oelang
Floating point calculations are only guaranteed to be platform independent
when you use the 'strictfp' modifier.

