Re: [Numpy-discussion] Psyco MA?

[Tim H. <tim...@ie...>]

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