[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