4 ms·

I'm really looking forward to the numpy specific announcements. Numpy is THE basic building for every single scientific library - if pypy can get a high perfor

by Fede_V 12y ago

I'm really looking forward to the numpy specific announcements. Numpy is THE basic building for every single scientific library - if pypy can get a high performance numpy, that will go a long way towards allowing scientific users to use pypy (there is still the detail of libraries that use the c-api to wrap c libraries, but cffi is pretty neat).

rcthompson 12y ago
If most of your code is numpy stuff, will you actually see a speedup from PyPy? (I mean hypothetically, once NumPyPy is properly optimized.)
- jre 12y ago
  In my experience, you'll have some parts of your code in which you have to do a for loop or something else that cannot be (cleanly) expressed using numpy and that's where performance starts to suffer. The current solution is to use something like cython, but if pypy simplifies that, I think that's great.
- dagss 12y ago
  Yes, ignoring that most people need a loop now and then, even pure NumPy-using code has a lot of potential. Consider "a + b + c + d". For large arrays, the problem is that it creates many temporary results of same size as original arrays that must be streamed over the memory bus. And since FLOPs are free and your computation is limited by memory bandwidth, you pay a large penalty for using NumPy (that gets worse as expression gets more complex). Or "a + a.T"... here you can get lots of speedup using basic tiling techniques, to fully use cache lines rather than read a cache line only to get one number and discard it. And so on. For numeric computation, there are large gains (like 2-10x) from properly using the memory bus, that NumPy can't take advantage of. So you have projects like numexpr and Theano that mainly focus on speeding up non-loop NumPy-using code.
- Fede_V 12y ago
  It highly depends. If it's just large linear algebra operations, then it won't matter, since all the work will be done by BLAS. If it's lots of small operations, I think pypy can inline them and you might see a significant speed up.
semi-extrinsic 12y ago
Personally, I'm not too excited about PyPy, because it has little promise of speeding up the two typical use cases for Python in the kind of scientific code I care about: 1. Python is used to setup/glue together code that is written in a compiled langugage. 2. Someone writes a code by starting out writing everything in Python, then profiling and identifying the slow parts, and then writing these in a compiled language. Edit: example of 1): HOOMD-blue, example of 2): PyClaw.
- sp332 12y ago
  If you're using pypy, the slow parts might not be slow anymore. It might even run faster than C, because JITs are better at some things than static compilers. http://morepypy.blogspot.com/2011/02/pypy-faster-than-c-on-carefully-crafted.html http://morepypy.blogspot.com/2011/02/pypy-faster-than-c-on-c...

by Fede_V 12y ago

rcthompson 12y ago

If most of your code is numpy stuff, will you actually see a speedup from PyPy? (I mean hypothetically, once NumPyPy is properly optimized.)

jre 12y ago
In my experience, you'll have some parts of your code in which you have to do a for loop or something else that cannot be (cleanly) expressed using numpy and that's where performance starts to suffer. The current solution is to use something like cython, but if pypy simplifies that, I think that's great.
dagss 12y ago
Yes, ignoring that most people need a loop now and then, even pure NumPy-using code has a lot of potential. Consider "a + b + c + d". For large arrays, the problem is that it creates many temporary results of same size as original arrays that must be streamed over the memory bus. And since FLOPs are free and your computation is limited by memory bandwidth, you pay a large penalty for using NumPy (that gets worse as expression gets more complex). Or "a + a.T"... here you can get lots of speedup using basic tiling techniques, to fully use cache lines rather than read a cache line only to get one number and discard it. And so on. For numeric computation, there are large gains (like 2-10x) from properly using the memory bus, that NumPy can't take advantage of. So you have projects like numexpr and Theano that mainly focus on speeding up non-loop NumPy-using code.
Fede_V 12y ago
It highly depends. If it's just large linear algebra operations, then it won't matter, since all the work will be done by BLAS. If it's lots of small operations, I think pypy can inline them and you might see a significant speed up.

semi-extrinsic 12y ago

Personally, I'm not too excited about PyPy, because it has little promise of speeding up the two typical use cases for Python in the kind of scientific code I care about: 1. Python is used to setup/glue together code that is written in a compiled langugage. 2. Someone writes a code by starting out writing everything in Python, then profiling and identifying the slow parts, and then writing these in a compiled language. Edit: example of 1): HOOMD-blue, example of 2): PyClaw.

sp332 12y ago
If you're using pypy, the slow parts might not be slow anymore. It might even run faster than C, because JITs are better at some things than static compilers. http://morepypy.blogspot.com/2011/02/pypy-faster-than-c-on-carefully-crafted.html http://morepypy.blogspot.com/2011/02/pypy-faster-than-c-on-c...