[pypy-dev] Contributing to pypy [especially numpy]

[David Cournapeau]

On Sun, Oct 16, 2011 at 5:34 PM, Stefan Behnel <stefan_ml at behnel.de> wrote:

>
> I wasn't comparing a JIT to another compiler. I was comparing it to a human
> programmer. A JIT, just like any other compiler, will never be able to
> *understand* the code it compiles, and it can only apply the optimisations
> that it was taught.

I don't understand your argument. There are *many* situations where
the best time to make a decision on how to generate machine code is
runtime, not offline compile time.

There are many things in numpy that are very difficult to get fast
because we can't know how to perform them without informations that
are only known at runtime, e.g.:

  - non-trivial iteration. The neighborhood iterators we have in numpy
are very slow because of the cost of function calls that can't really
be bypassed unless you start to generate hundred or even more small
functions for each special case (number of dimensions, is the stride
value == item size, etc...)
  - anything that requires specialization on the type. A typical
example is the sparse array code in scipy.sparse. Some code is C++
code that is templated on the contained value and index size. But
because the generated code is so big, we need to restrain the
available types, otherwise we would need to compile literally thousand
of functions which are doing exactly the same. Even if most people
don't use most of them.

One area where JIT is not that useful is to replace existing fortran/c
code. Not only I am doubtful about have JIT beating Intel compiler for
linear algebra stuff, but more significantly, rewriting the existing
codebase would take many man-years. Some of this code requires deep
knowledge of the underlying computation, and there is also the issue
of correctness in floating point code generation. Given that
decade-old compilers get it wrong, I would expect pypy jit to have
quite a few funky corner cases as well.

cheers,

David