[Python-Dev] Python is faster than C (original) (raw)

Dave Cole djc at object-craft.com.au
Mon Apr 5 19:06:16 EDT 2004

On Tue, 2004-04-06 at 00:36, Tom Emerson wrote:

Moore, Paul writes: > 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?

If I understand correctly, the issue is that when stdlib functions are rewritten in C, they end up being faster but are still slower than Psyco optimized code because they are still polymorphic while the Psyco'ized generates multiple paths. If that is the case then one could certainly hand-hack the C implementations to expand common code paths in an optimal way.

I have not looked at Psyco so could be operating from a misunderstanding of what it does...

Would it make sense to build specialisation into the base Python interpreter so that it builds specialised versions of bytecode for functions. I am assuming that there are only a few types that can be targeted by specialisation (int, float). Bytecodes then could be added to the interpreter which operate on those native machine types rather than the Python objects.

This has the advantage of allowing specialisation on all currently supported platforms and does not preclude the further optimisation of translation to machine code.

If specialisation was in the base interpreter then I suppose it should possible for the compiler to know when a native machine type can be compiled directly. For example:

def foo(): i = 0 while i < 100: bar() i += 1

While noone writes loops like that, it does illustrate the point. It is clear that the local i is always an integer and is not used outside the function.

-- http://www.object-craft.com.au

More information about the Python-Dev mailing list