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.gay...@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 <ar...@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
