[pypy-dev] PyPy doesn't make code written in C faster

[Armin Rigo]

Hi Nathan,

On Fri, May 31, 2013 at 5:48 PM, Nathan Hurst <njh at njhurst.com> wrote:
> For what it's worth, the time for str(long) / time for recursive
> algorithm does decrease steadily for increasing input lengths.  But
> it's not n^2 / n log n.  Perhaps we need to implement a faster divmod?

Actually I found an old but still in-progress bug report for CPython:

    http://bugs.python.org/issue3451

It contains all these questions and more.  CPython seems mainly
blocked by lack of man-power sufficient to review all the reference
counting mess.  That seems like a good reason to write the algorithms
in PyPy first :-)

> But to the main point: is it fair for people to compare code which
> doesn't get the benefit of pypy? Yes it is.  Because the majority of
> code out there today is going to have C calls.  Sure, pypy will lose
> on those, but that provides incentive to fix the problem - for
> example, implementing a better long to string.
>
> People are going to write silly benchmarks and they are going to solve
> problems in silly ways.  We should be honest about this in the
> benchmarks.  Don't worry, pypy will do just fine.

Yes, I believe you are right.  We should really add these kinds of
benchmarks too.  It's a trap that is natural to fall into, and we
should continue to motivate the reasons for why PyPy is not 5 times
faster than CPython here.


A bientôt,

Armin.