[pypy-dev] PyPy doesn't make code written in C faster
arigo at tunes.org
Fri May 31 18:05:57 CEST 2013
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:
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.
More information about the pypy-dev