Lua is faster than Fortran???

[sturlamolden]

On 9 Jul, 05:39, Felix <schle... at cshl.edu> wrote:

> This is something that I have been thinking about recently. Python has
> won quite a following in the scientific computing area, probably
> especially because of great libraries such as numpy, scipy, pytables
> etc.

Python is much more friendly to memory than Matlab, and a much nicer
language to work in. It can also be used to program more than just
linear algebra. If you have to read data from a socket, Matlab is not
so fun anymore.

> But it also seems python itself is falling further and further
> behind in terms of performance and parallel processing abilities.

First, fine-grained parallelism really belongs in libraries like MKL,
GotoBLAS and FFTW. Python can manage the high-level routines just like
Matlab. You can call a NumPy routine like np.dot, and the BLAS library
(e.g. Intel MKL) will do the multi-threading for you. We almost always
use Python to orchestrate C and Fortran. We can use OpenMP in C or
Fortran, or we can just release the GIL and use Python threads.

Second, the GIL it does not matter for MPI, as it works with
processes. Nor does it matter for os.fork or multiprocessing. On
clusters, which are as common in high-performance computing as SMP
systems, one has to use processes (usually MPI) rather than threads,
as there is no shared memory between processors. On SMP systems, MPI
can use shared-memory and be just as efficient as threads (OpenMP).
(MPI is usually faster due to cache problems with threads.)

Consider that Matlab does not even have threads (or did not last time
I checked). Yet it takes advantage of multi-core CPUs for numerical
computing. It's not the high-level interface that matters, it's the
low-level libraries. And Python is just that: a high-level "glue"
language.

> For an outsider it does not look like a solution to the GIL mess or a
> true breakthrough for performance are around the corner (even though
> there seem to be many different attempts at working around these
> problems or helping with parts). Am I wrong?

Yes you are.

We don't do CPU intensive work in "pure Python". We use Python to
control C and Fortran libraries. That gives us the opportunity to
multi-thread in C, release the GIL and multi-thread in Python, or
both.