<br><div class="gmail_quote">On Fri, Nov 9, 2012 at 4:59 AM, Joe Landman <span dir="ltr"><<a href="mailto:landman@scalableinformatics.com" target="_blank">landman@scalableinformatics.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<br>
As to the point of code being written in Python/R/...  Mebbe thats not<br>
such a good idea (Python).  R, Matlab, Octave,... are interpreted as<br>
well.  Compiled langs to a VM are ok (Java, Perl6, Julia), but best<br>
performance is going to statically compiled code.  This said, the Julia<br>
people are doing their absolute best to be on par with statically<br>
compiled code, and its coming very close.<br></blockquote><div><br>Not sure why you single out Python as bad or hold up Perl as good. Python (like Java, Perl, Julia, and probably all the others) is run in a VM.  In fact there are Python implementations on the JVM (<a href="http://www.jython.org/">http://www.jython.org/</a>) and Microsoft's CLR (<a href="http://ironpython.net/">http://ironpython.net/</a>). The reason Java tends to outperform the others is because it is less dynamic and thus it is easier for the VM to do some static tricks to speed up execution. To get really good performance from highly dynamic languages you need a VM with good JIT compilation. This is the point of the PyPy project for Python (<a href="http://pypy.org/">http://pypy.org/</a>) and this is how Julia gets its impressive speed.<br>
<br>As someone with a C/C++ programming background who does most of my current development (of scientific HPC applications) in Python, I would like to point out a couple of other things: <br> <br>1) Unless you are writing a single purpose library like BLAS or LAPACK, the majority of your code is probably not going to be performance critical.  <br>
<br>2) The scientific libraries for high level languages (e.g. Numpy and Scipy for Python) are wrappers for low level code (BLAS, LAPACK, custom C/C++).<br><br>3) If you do need to do some computation in a tight loop (that is not provided by a low level library) you can easily plug in a little bit of C/C++. Options (roughly in order of increasing effort) include: using a string of C++ code with some variable mappings (<a href="http://www.scipy.org/Weave">http://www.scipy.org/Weave</a>), statically typing certain variables so that the code can be translated into efficient C (<a href="http://cython.org/">http://cython.org/</a>), writing the code with a restricted subset of python than can be translated to C (<a href="http://doc.pypy.org/en/latest/translation.html">http://doc.pypy.org/en/latest/translation.html</a>), or using plain old ctypes (<a href="http://docs.python.org/2/library/ctypes.html">http://docs.python.org/2/library/ctypes.html</a>). There is a nice comparison (<a href="http://www.scipy.org/PerformancePython">http://www.scipy.org/PerformancePython</a>) of using some of these options to solve  Laplace's equation. The fastest Cython implementation takes 2.3 seconds (for a 500x500 grid) while the pure C++ version takes 2.16 seconds.<br>
<br>- Brendan<br></div></div>