5 ms·

NumPy in PyPy - status and roadmap

44 points by kingkilr 15y ago

andrewcooke 15y ago
it's a pity that they need to implement this in RPython. if it really is for only a tiny set of functionality (like SSE functions) couldn't they just implement that part? perhaps in a general sse library that other people could use? or as PyPy extensions?
- wtallis 15y ago
  I'm not sure I understand what you're saying here. The stuff that has to be re-written is everything in Numpy that is performance-critical and currently written in C. Given the nature of Numpy, that's almost everything. The only alternative would be to make PyPy compatible enough with CPython to be able to load Numpy, but that would prevent you from taking advantage of many of PyPy's best features. The only tiny set of functionality referenced in the article is the portion of Numpy which has already been rewritten as a proof of concept. Much, much more still has to be done before there is a generally useful version of Numpy for PyPy.
  - andrewcooke 15y ago
    the idea behind pypy is that python code should be efficient. so you would expect them to rewrite numpy in python. they are not doing that. they are using rpython instead. rpython is lower level. it is what is used to write the core of pypy. which raises the question - when should people use rpython rather than python? and that is answered, at the link, by someone saying that people should almost always use python, not rpython. the need for rpython here is based on low level considerations like access to sse instructions. [edit: where i wrote "couldn't they just implement that part?" i meant "couldn't they just implement that part in rpython and the rest in python?". hopefully that and the above clarifies things.]
    - DasIch 15y ago
      What about hints to the JIT and other things you can do at that level? This is a decision being made by people having worked on PyPy for years, if there is anyone who is able to make a good decision about when to use rpython instead of python they are.
      - andrewcooke 15y ago
        if hints to the jit are important here, why aren't they going to be important in other places too? is numpy really so unusual? or is every performance-critical library going to end up in rpython? and sorry if thinking for myself rather than blindly trusting others offends you.
        baltcode 15y ago
        The idea is that most of the regular numpy (for CPython) is not written in Python anyway. It is actually written in C. For PyPy, they will be writing major portions of it in RPython instead of C, and RPython is way more high level than C.
        andrewcooke 15y ago
        i know numpy is largely written in c. i am not sure whether i am incompetent at explaining myself, or if people simply are not reading what i post. my point, again, is that pypy is supposed to give speed comparable to c (particularly in tight loops that don't have changes of type, which you would imagine numpy to be) without needing to write in either c or rpython - you can just use python. and this is confirmed by the poster on that thread, who said that numpy was exceptional, and that other people should not need to use rpython... my original comment, then, was that perhaps whatever was unusual could itself be abstracted out and made available at the python level. it's really not that hard to understand, is it? :o(
        wtallis 15y ago
        The "unusual code" portion of numpy is the entirety of numpy. It's BLAS for Python. Once it's well-optimized, basically any other numerical code or libraries for python (things like scipy and probably large portions of PIL, and applications built on them) should do reasonably well written in pure python running on PyPy. The JIT in PyPy should be able to offer good performance for non-numerical, dynamic, branchy code, so you will very rarely have to drop down to a lower-level language (C or RPython) except for FFI. JITs can help with tight loops that can't be identified and optimized at compile time, but that's not what Numpy is composed of, and code using numpy shouldn't have to go through several iterations before the Numpy routines get identified as hotspots and optimized. Numpy implements algorithms that are designed to be easy to statically compile into machine language code that makes efficient use of memory, FPU, and cache resources.
  - deleted 15y ago
    [deleted]

44 points by kingkilr 15y ago

it's a pity that they need to implement this in RPython. if it really is for only a tiny set of functionality (like SSE functions) couldn't they just implement that part? perhaps in a general sse library that other people could use? or as PyPy extensions?

wtallis 15y ago
I'm not sure I understand what you're saying here. The stuff that has to be re-written is everything in Numpy that is performance-critical and currently written in C. Given the nature of Numpy, that's almost everything. The only alternative would be to make PyPy compatible enough with CPython to be able to load Numpy, but that would prevent you from taking advantage of many of PyPy's best features. The only tiny set of functionality referenced in the article is the portion of Numpy which has already been rewritten as a proof of concept. Much, much more still has to be done before there is a generally useful version of Numpy for PyPy.
- andrewcooke 15y ago
  the idea behind pypy is that python code should be efficient. so you would expect them to rewrite numpy in python. they are not doing that. they are using rpython instead. rpython is lower level. it is what is used to write the core of pypy. which raises the question - when should people use rpython rather than python? and that is answered, at the link, by someone saying that people should almost always use python, not rpython. the need for rpython here is based on low level considerations like access to sse instructions. [edit: where i wrote "couldn't they just implement that part?" i meant "couldn't they just implement that part in rpython and the rest in python?". hopefully that and the above clarifies things.]
  - DasIch 15y ago
    What about hints to the JIT and other things you can do at that level? This is a decision being made by people having worked on PyPy for years, if there is anyone who is able to make a good decision about when to use rpython instead of python they are.
    - andrewcooke 15y ago
      if hints to the jit are important here, why aren't they going to be important in other places too? is numpy really so unusual? or is every performance-critical library going to end up in rpython? and sorry if thinking for myself rather than blindly trusting others offends you.
      - baltcode 15y ago
        The idea is that most of the regular numpy (for CPython) is not written in Python anyway. It is actually written in C. For PyPy, they will be writing major portions of it in RPython instead of C, and RPython is way more high level than C.
        andrewcooke 15y ago
        i know numpy is largely written in c. i am not sure whether i am incompetent at explaining myself, or if people simply are not reading what i post. my point, again, is that pypy is supposed to give speed comparable to c (particularly in tight loops that don't have changes of type, which you would imagine numpy to be) without needing to write in either c or rpython - you can just use python. and this is confirmed by the poster on that thread, who said that numpy was exceptional, and that other people should not need to use rpython... my original comment, then, was that perhaps whatever was unusual could itself be abstracted out and made available at the python level. it's really not that hard to understand, is it? :o(
        wtallis 15y ago
        The "unusual code" portion of numpy is the entirety of numpy. It's BLAS for Python. Once it's well-optimized, basically any other numerical code or libraries for python (things like scipy and probably large portions of PIL, and applications built on them) should do reasonably well written in pure python running on PyPy. The JIT in PyPy should be able to offer good performance for non-numerical, dynamic, branchy code, so you will very rarely have to drop down to a lower-level language (C or RPython) except for FFI. JITs can help with tight loops that can't be identified and optimized at compile time, but that's not what Numpy is composed of, and code using numpy shouldn't have to go through several iterations before the Numpy routines get identified as hotspots and optimized. Numpy implements algorithms that are designed to be easy to statically compile into machine language code that makes efficient use of memory, FPU, and cache resources.
- deleted 15y ago
  [deleted]