[Stackless] Slowdown when running Numpy with Stackless?

Christian Tismer tismer at stackless.com
Wed May 8 14:39:04 CEST 2013


Hey guys,

On 08.05.13 04:31, Bin Huang wrote:
> On Tue, May 7, 2013 at 6:54 PM, Richard Tew <richard.m.tew at gmail.com> wrote:
>> On Wed, May 8, 2013 at 8:17 AM, Bin Huang <bin.arthur at gmail.com> wrote:
>>> Hi Richard,
>>>
>>> So I was able to compile with STACKLESS_OFF and manual removal of
>>> 'static'. I measured the performance again:
>>>
>>> Problem size    CPython             Stackless           Stackless_off
>>> 256x256           14.106 ms          39.331 ms          39.394 ms
>>> 512x512           110.648 ms        346.857 ms        350.049 ms
>>> 1024x1024       1022.090 ms      8949.712 ms      8926.275 ms
>>> 2048x2048       7795.782 ms      80161.503 ms    78647.046 ms
>>>
>>> Then I obtained the source code for official Python 2.7.2 tarball
>>> release and repeated the
>>> process. Freshly installed Python 2.7.2 also showed slowdown. Clearly,
>>> it is how
>>> to install stackless Python and Numpy that matters.
>> Okay, if I understand you correctly, you tested official Python 2.7.2
>> tarball, and it was similar to the numbers for Stackless_off?  The
>> official Python 2.7.2 tarball is not the cpython column, right?
> That's correct. The CPython column I listed was the default Python installation
> on my machine. And in fact its version is 2.7.3.
>
>> If this is the case, that any straight download and compilation of the
>> Python source code (whether Stackless or not) gives you similar slow
>> numbers, then there's something special about whatever gave the
>> numbers for cpython.
>>
>>> Is there anything special that you think I need to pay attention to?
>> Yes, the Stackless_off column.  Stackless_off is official Python.  It
>> completely compiles out the "Stackless patch" and should give
>> something that behaves exactly like the official Python with the same
>> version.  So, your official tarball compile should give you the same
>> numbers as Stackless_off.
> I like it. I can see that the switch "stackless_off" makes debugging like this
> much easier.
>
>>> Thanks!
>> No, thank you for going to all this work.  I expect your cpython is
>> either 2.7.3, and if so, you should get comparable numbers from the
>> 2.7.3 stackless source code.  Or it is installed from the packaging
>> system for your operating system and it compiles as 64 bit or
>> something different.  Unless you are going to tell me that I
>> misunderstood, and that your cpython column was for the official 2.7.2
>> tarball, I do not think your problem lies with Stackless.
>>
> You just made a good point. So I went ahead and downloaded an official
> 2.7.3 tarball and repeated the same process. Guess what? Same slowdown
> happened to official 2.7.3 tarball.
>
>> Hope this helps.
> It really helps. Now I believe the problem is related to how I installed Numpy.
> I actually had two Numpy installations. One was installed by packaging system
> (which has superior performance) and the other was by myself manually.
> It is time to bother Numpy community :-).
>

That was a very interesting conversation!
Please let me know what the crucial problem with Numpy was.
Is that maybe related to continuum's Numba, maybe even Jit code?

cheers - chris

-- 
Christian Tismer             :^)   <mailto:tismer at stackless.com>
Software Consulting          :     Have a break! Take a ride on Python's
Karl-Liebknecht-Str. 121     :    *Starship* http://starship.python.net/
14482 Potsdam                :     PGP key -> http://pgp.uni-mainz.de
phone +49 173 24 18 776  fax +49 (30) 700143-0023
PGP 0x57F3BF04       9064 F4E1 D754 C2FF 1619  305B C09C 5A3B 57F3 BF04
       whom do you want to sponsor today?   http://www.stackless.com/




More information about the Stackless mailing list