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

[Maciej Fijalkowski]

On Sun, Oct 16, 2011 at 6:34 PM, Stefan Behnel <stefan_ml at behnel.de> wrote:
> 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.

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). Granted, you might want to have an
access to emitting assembler on the fly and do it better than a
compiler, but sometimes you need a way to emit assembler on the fly.

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

We still have to implement JITs in something :)