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

Stefan Behnel stefan_ml at behnel.de
Sun Oct 16 18:34:58 CEST 2011

Maciej Fijalkowski, 16.10.2011 17:50:
> On Sun, Oct 16, 2011 at 2:29 PM, Stefan Behnel wrote
>> Samuel Vaiter, 14.10.2011 17:59:
>>> The main
>>> reason why Numpy is my main interest is that as Ph.D student in
>>> Applied Mathematics, I really hope one day we will be able to perform
>>> numerical computation without using heavy binding in C/Fortran or
>>> intermediate solution like Cython.
>> I guess you didn't mean it that way, but "intermediate solution" makes it
>> sound like you expect any of these to go away one day. They sure won't.
>> Manually optimised C and Fortran code will always beat JIT compilers,
>> especially in numerics. It's a game they can't win - whenever JIT compilers
>> get too close to hand optimised code, someone will come along and write
>> better code.
> I guess what you say is at best [citation needed].

Feel free to quote me. :D

> 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.

Mind you, I'm not saying that JIT compilers aren't capable of generating 
surprisingly fast code. They certainly are, and what they deliver is often 
"good enough". I'm just saying that statically compiled low-level languages 
will *always* have a raison d'être, if only to deliver support for the "I 
know what I'm doing" cases.


More information about the pypy-dev mailing list