[prev in list] [next in list] [prev in thread] [next in thread] 

List:       pypy-dev
Subject:    Re: [pypy-dev] PyPy is much slower than CPython example / question
From:       Alexander Petrov <alexandervpetrov () gmail ! com>
Date:       2011-07-20 6:50:20
Message-ID: CALHu_X9WSGqWQ+oOJkB1gjVBsYQbqnMXoe1UYRHNcCWLG_MNNw () mail ! gmail ! com
[Download RAW message or body]

Thanks to all for the answers.
Small remarks.

I remember, I wrote such code (using itertools.repeat with slices)
after spending near a day measuring performance of some syntactical
constructs usually in several algorithms dealing with numbers... So I
was trying to produce a sort of Python coding style for myself in that
area - what constructs in what situations gave stable speed
improvement and are stiil good-readable-pythonic. After that in all
projects I used such things, e.g. using slice-with-repeat for
assignment of constant, in prefer to for-loop or list-comprehension.

Calculating primes by naive Eratosthene's sieve - is example of
algorithm where a big part of calculation required to go beyong
processor cache, so I suppose its performance is more characteristic
of language-tools than very-low-level-compler-opmization or hardware
architecture. Frankly speaking it was second piece of code that I have
tested with PyPy - and suprised with such results :)

Another one example I discovered where PyPy is slower is big numbers
arithmetic (e.g. try to generate members of some recurrently defined
sequence, such as Fibonacci, in a simple loop).

===============

So at this time I didn't come to some kind of decision about PyPy.

On one hand in most of the cases with straitforward code/algorithms
and "common" syntax constructs there was significant speed
improvement.

But on the other hand, for the cases where source Python code was
"optimized" or "hacked" the time of execution was sometimes better,
sometimes of one order... and sometimes was a cause for this topic
discussion. :) It is not bad thing generally, the bad thing that this
speed degradation situations are happenned unexpectedly for me. IMO
they are the most (and may be only one) interesting from the PyPy-user
viewpoint. "Where and in what cases one can expect bottlenecks". Is
there any documented collection of such artifacts? It can be
exceptionally useful.

Alex.

On Sat, Jul 9, 2011 at 07:40, Alex Gaynor <alex.gaynor@gmail.com> wrote:
> I'm not too sure what could be better wrong with it, it's rather
> short: https://bitbucket.org/pypy/pypy/src/default/pypy/module/itertools/interp_itertools.py#cl-85
> Alex
>
> On Fri, Jul 8, 2011 at 2:18 AM, Armin Rigo <arigo@tunes.org> wrote:
>>
>> Hi Alex,
>>
>> Before attacking the problem with the JIT, we should understand better
>> why PyPy is 4-8 times slower than CPython.  Normally you'd expect the
>> factor to be at most 2.  I suppose the answer is that our
>> itertools.repeat() is bad for some reason.
>>
>>
>> A bientôt,
>>
>> Armin.
>
>
>
> --
> "I disapprove of what you say, but I will defend to the death your right to
> say it." -- Evelyn Beatrice Hall (summarizing Voltaire)
> "The people's good is the highest law." -- Cicero
>
>
_______________________________________________
pypy-dev mailing list
pypy-dev@python.org
http://mail.python.org/mailman/listinfo/pypy-dev

[prev in list] [next in list] [prev in thread] [next in thread]