[erlang-questions] Erlang and/or MPI

[Richard A. O'Keefe]

On 1/07/2013, at 7:21 AM, Jesper Louis Andersen wrote:

> On Thu, Jun 27, 2013 at 3:26 AM, Richard A. O'Keefe <ok@REDACTED> wrote:
> 
> Except for commands typed at the shell, Erlang is compiled, not interpreted.
> And there is a native code generator; c(File, [native]) does the trick if
> native code generation was enabled at build time.
> And the native code generator exploits -spec declarations (and some type
> inference) to avoid boxing floats some of the time.
> 
> 
> It is bytecode interpreted to be precise. It is faster than blind AST-interpretation, but it is not really what I would call compiled in the sense of compiled-to-native-code. The native code generator can help for certain types of programs, but it does not yield enough speedup to make it interesting in my opinion.

If the native code back end was installed when your Erlang system was
installed - and it should be under Linux and Solaris at least - and
you compile with c(File, [native]) you will get *native* code,
not 'bytecode interpreted'.

Way back when Quintus was making the world's finest Prolog system,
our system compiled to threaded code (not byte code) that was emulated
in macro-generated assembler (not C).  We observed that
 - on tiny programs, native code systems were about a factor of 2 faster;
 - on medium programs, we were neck and neck;
 - on large programs (defined as 100 pages of source code), we were
   at least a factor of 2 faster.
I leave it as an exercise for the reader to figure out why this might
be so.

There was one time I wanted to analyse some benchmark data, and typed
in a Fortran program from a book.  I just couldn't get it working, so
I rewrote it from scratch in Prolog.  Once I had done that I was able
to find the bug fairly quickly.  The amusing thing was that the Prolog
code was faster than the native-compiled Fortran.

That one I'll explain:  I used a better data structure.  Asymptotic
factors really can win over constant factors.

In a distributed system, it's astonishingly easy for costs to be
dominated by the cost of getting data from one place to another,
with the actual time to compute being minor.  No, I'm not saying
that it's _always_ the case, just that it's easy to write a program
where that's true _without meaning to_.
For anyone using MPI,
http://www.netlib.org/utk/people/JackDongarra/PAPERS/perftools-review2.pdf
may still be useful.

Erlang's debugging and tracing tools could be quite helpful.