[Python-Dev] Python is faster than C

Armin Rigo arigo at tunes.org
Mon Apr 5 09:23:16 EDT 2004

Hello Paul,

On Mon, Apr 05, 2004 at 01:54:38PM +0100, Moore, Paul wrote:
> I got the impression that Armin's point was that Psyco can optimise
> the integer case *if* the code is in Python, but not if it's in C.


> [Armin, how does Psyco + a Python sort compare against timsort on
> more general objects?]

Psyco suffers its current general problem: if you are using an operation that
hasn't been explicitely recoded in Psyco (like tuple comparison) then the
optimization wanishes.  Sorting a list of (integer, complex_object), which is
more common in practice, is 1.5x slower with Python+Psyco.  I am sure that
with 30 minutes of effort in the proper code I can make it faster than Timsort
again.  But Psyco has the same general problem everywhere.

I think that Psyco isn't ready for real uses yet because you just can't
predict the resulting performance unless you know its internals.  My hope with
PyPy is that it will change that, by giving a way to generate all these
missing Psyco parts automatically from the PyPy source, but that's still a
long way.  I won't even mention that Psyco works well only on 386.  (It has
got an almost-ready platform-independent back-end, but that's slower, so it is
only a win in more extreme cases.)

> Hmm. I'm torn. On the one hand, it's really cool that Python+Psyco can
> out-perform C (another argument against the knee-jerk "recode bits in
> C" reaction). But my gut feel is that not enough people use Psyco to
> make this a good answer yet. On the third hand, if we recode chunks of
> the stdlib in C, do we kill too many chances for Psyco to work its
> magic?

I think that (re)coding in C is very positive right now.  And if we don't
actually loose the original Python source (if there is one) then we don't
really loose the ability to revert to it if at some point it is consistently

Essentially, I wanted to rant about the fact that some performance
considerations are driving the language's evolution, and this is much harder
to revert to if later the performance reasons vanish.

A bientot,


More information about the Python-Dev mailing list