Hacker News Reader

Comment by fijal | Hacker News Reader

No, PyPy JITs all the Python by design. It also runs all the Python and JITs all the constructs. It does not make all the possible python magically faster however, but that does not change my point. A JIT for only a restricted subset of Python would mean that it segfaults/crashes/gives a wrong answer if you don't provide a correct subset. This is not true.

View on HN

So basically you're saying that PyPy knows what code it can optimize and Numba requires the programmer to specify it. That probably has more to do with Numba's being version 0.2 than anything else. And it's hardly reason to moan that it's not a "real" compiler.

I did not call it not a "real" compiler (with or without quotes), I did call it not a python compiler. It has nothing to do with 0.2 - supporting all of Python is probably not even within goals of the numba project. I'm not talking about "all the bytecodes", but making sure all the corner cases work perfectly well etc. Also supporting all cases would mean that you get rid of a lot of speed benefits that you see right now, precisely because you don't care about all the corner cases. Predicting the future is obviously hard and I can't speak on behalf of numba authors, but I don't think there are plans to support all of Python.

Python code goes in, LLVM IR comes out. Sounds like a compiler to me.

As you know, the basic idea of the project is to make writing fast, vectorized code for numerical and scientific computations as easy as writing native Python. And to do it in a way that maintains compatibility with the extensive CPython universe.

I think the criticism you're fishing for is that it is not an implementation of Python. No, it's not that. But, yes, it is a compiler.

No, it's not. There is one more requirement - the LLVM IR has to work exactly the same as intended for python (in this case as cpython does). This is not the case - it's not full and what's implemented does not support all the corner cases of the language, starting with overflow-to-long.

Just asking... How it would compare to PyPy's RPython?

Different purpose, different restrictions. Numba is written to support fast numpy ufuncs (without resorting to C) and the like. RPython is a proper subset of Python (so all corner cases either work or are declared "not RPython", you can't get a different answer) which supports more of a language but with less of integration with the host interpreter.

Reply on news.ycombinator.com