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

[Carl Friedrich Bolz]

On 29/06/13 20:06, Nathan Hurst wrote:
> I don't actually see any difference between that code and normal
> python.  What makes it rpython?

Being RPython is mostly a contextual property. It does nothing "too
dynamic", so it is RPython.


>> The main changes I did from your version was generalize it to work for
>> any 3 <= n <= 36, optimize the handling of leading zeros and use a
>> StringBuilder instead of a list to build the resulting string. Plus I
>> kept the already existing fast version for powers of two alive.
> 
> All good decisions.  Is there a nice way to profile this with
> something like line_profiler?  It's possible to improve the
> asymptotics in various places, but they almost certainly aren't worth
> it.

For rbigint I just profiled the generated C source.

> Of course the real question is whether pypy now beats python2.7 on the
> all important factorial benchmark.  (And if so should we rush out a
> new release? ;)

Yes, it does, and it will be in the 2.1 release.

I also did some additional changes yesterday:

https://bitbucket.org/pypy/pypy/commits/7ceb58dbdc244439b58d8bcc2d5e41a35fa3897b

(and following commits)

I now cache the powers of base needed to split the number, because the
profile was completely dominated by calls to pow. In addition, I
compute the minimum digits based on the base, instead of using a
pessimistic bound for all bases.

Now the profile is actually dominated by calls to divmod, which is
probably expected.

Cheers,

Carl Friedrich