On Sun, Oct 16, 2011 at 5:34 PM, Stefan Behnel <stefan...@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 _______________________________________________ pypy-dev mailing list pypy-dev@python.org http://mail.python.org/mailman/listinfo/pypy-dev