[Beowulf] Maker2 genomic software license experience?

[Brendan Moloney]

On Fri, Nov 9, 2012 at 4:59 AM, Joe Landman <landman at scalableinformatics.com
> wrote:

>
> As to the point of code being written in Python/R/...  Mebbe thats not
> such a good idea (Python).  R, Matlab, Octave,... are interpreted as
> well.  Compiled langs to a VM are ok (Java, Perl6, Julia), but best
> performance is going to statically compiled code.  This said, the Julia
> people are doing their absolute best to be on par with statically
> compiled code, and its coming very close.
>

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 (http://www.jython.org/)
and Microsoft's CLR (http://ironpython.net/). 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 (
http://pypy.org/) and this is how Julia gets its impressive speed.

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:

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.

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

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 (http://www.scipy.org/Weave),
statically typing certain variables so that the code can be translated into
efficient C (http://cython.org/), writing the code with a restricted subset
of python than can be translated to C (
http://doc.pypy.org/en/latest/translation.html), or using plain old ctypes (
http://docs.python.org/2/library/ctypes.html). There is a nice comparison (
http://www.scipy.org/PerformancePython) 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.

- Brendan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.beowulf.org/pipermail/beowulf/attachments/20121109/66307e1f/attachment.html>