Maciej Fijalkowski, 16.10.2011 20:01:
On Sun, Oct 16, 2011 at 6:34 PM, Stefan Behnel wrote:
Maciej Fijalkowski, 16.10.2011 17:50:
We have proven
already that we can perform several optimizations that are very hard
to perform at the C level. And indeed, while you can always argue
"well, you can just write a better compiler", it's true also for JITs.
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. JITs are nice when you need performance quickly and
don't care about the last few CPU cycles. However, there are cases where
it's not very satisfactory to learn that your JIT compiler, in the current
state that it has, can only get you up to, say, 90%, or even 95% of the
speed that you need for your problem. In those cases where you do care about
the last 5%, and numerics people care about them surprisingly often, you
will eventually end up using a low-level language, usually C or Fortran, to
make sure you get as much out of your code as possible. JIT compilers are
structurally much harder to manually override than static compilers, and
they are certainly not designed to help with the "but I know what I'm doing"
cases.
I just claim you're wrong here and there are cases where you can't
beat the JIT compiler, precisely because some stuff depends on runtime
data and you can't encode all the possibilities in a statically
compiled code (at least in theory).
Regarding David's response, I agree that there are cases where JITs can
help in limiting the code explosion that you'd get from statically
generating all possible optimised cases for generic code. A JIT only needs
to instantiate the cases that really exist at runtime. Obviously, that does
not automatically mean that the JIT would generate code that is as fast or
faster than what a programmer would write for *one* of the specific cases
by tuning the code accordingly. It just means that it would generate better
code *on average* when looking at the whole corpus, because it can simply
(and quickly) adapt the code to more cases at need. If that's what the
programmer wants depends on the use case. I see the advantage for that
especially in library code that needs to deal with basically all cases
efficiently, as David pointed out.
Stefan
_______________________________________________
pypy-dev mailing list
pypy-dev@python.org
http://mail.python.org/mailman/listinfo/pypy-dev
