[Numpy-discussion] Psyco MA?
Tim Hochberg
tim.hochberg at ieee.org
Mon Feb 10 08:53:04 EST 2003
Chris Barker wrote:
>Tim Hochberg wrote:
>
>
>>Psyco seems fairly stable these days. However it's one of those things
>>that probably needs to get a larger cabal of users to shake the bugs out
>>of it. I still only use it to play around with because all things that I
>>need speed from I end up doing in Numeric anyway.
>>
>>
>
>Hmmm. It always just seemed too bleeding edge for me to want to drop it
>in inplace of my current Python, but maybe I should try...
>
>
I think Psyco was a reworked interpreter at some point, but it isn't any
longer. Now it's just an extension module. You typically use it like this:
def some_function_that_needs_to_be_fast(...):
....
psyco.bind(some_function_that_needs_to_be_fast)
Of course, it's still possible to bomb the interpreter with Psyco and
it's a huge memory hog if you bind a lot of functions. On the other hand
in the course of playing with psymeric I found one way to crash the
interpreter with Psyco, one way with Numeric, and one way to cause
Numarray to fail, although this did not crash the interpreter. So if I
was keeping a tally of evil bugs, they'd all be tied right now....
>>For Psyco at least you don't need a multidimensional type. You can get
>>good results with flat array, in particular array.array. The number I
>>posted earlier showed comparable performance for Numeric and a
>>multidimensional array type written all in python and psycoized.
>>
>>
>
>What about non-contiguous arrays? Also, you pointed out yourself that
>you are still looking at a factor of two slowdown, it would be nice to
>get rid of that.
>
>
Non contiguous arrays are easy to build on top of contiguous arrays,
psymeric works with noncontiguous arrays now. If you'd like, I can send
you some code.
The factor of two slowdown is an issue. A bigger issue is that only x86
platforms are supported. Also there is not support for things like
byteswapped and nonalligned arrays. There also might be problems getting
the exception handling right. If this approach were to be done "right"
for heavy duty number cruncher types, it would require a more capable,
c-based, core buffer object, with most other things written in python
and psycoized. This begins to sounds a lot like what you would get if
you put a lot of psyco.bind calls into the python parts of Numarray now.
On the other hand, it's possible some interesting stuff will come out of
the PyPy project that will make this thing possible in pure Python. I'm
watching that project wit interest.
I did some more tuning of the Psymeric code to reduce overhead and this
is what the speed situation is now. This is complicated to compare,
since the relative speeds depend on both the array type and shaps but
one can get a general feel for things by looking at two things: the
overhead, that is the time it takes to operate on very small arrays, and
the asymptotic time/element for large arrays. These numbers differ
substantially for contiguous and noncontiguous arrays but there relative
values are fairly constant across types. That gives four numbers:
Overhead (c) Overhead (nc)
TimePerElement (c) TimePerElement (nc)
NumPy 10 us 10
us 85 ps 95 ps
NumArray 200 us 530 us
45 ps 135 ps
Psymeric 50 us 65
us 80 ps 80 ps
The times shown above are for Float64s and are pretty approximate, and
they happen to be a particularly favorable array shape for Psymeric. I
have seen pymeric as much as 50% slower than NumPy for large arrays of
certain shapes.
The overhead for NumArray is suprisingly large. After doing this
experiment I'm certainly more sympathetic to Konrad wanting less
overhead for NumArray before he adopts it.
-tim
More information about the NumPy-Discussion
mailing list