Python un-plugging the Interpreter

DillonCo dillonco at comcast.net
Thu Apr 19 17:55:46 EDT 2007


On Thursday 19 April 2007, S.Mohideen wrote:
>  2) Making the program to run at par with the compiled version of C/C++
> program- this is the main benefit which can be derived out of this.

Python is a rather slow language because of how it works.  Even if you got rid 
of the VM (as noted by others, Python compiles into VM code), Python would 
still be slower than C, and probably by a large margin.

Look at the "+" operator for instance. In C, this translates directly to and 
add instruction that takes something like 1 cycle.  Very fast.  In python, it 
translates (very) roughly to:

def add(a,b):
    if issubclass(b,a):
        try:
            return b.__dict__['__radd__'](a)
        catch:
            return a.__dict__['__add__'](b)
    else:
        try:
            return a.__dict__['__add__'](b)
        catch:
            return b.__dict__['__radd__'](a)

So for 2+2, you'll have to go through "issubclass", then look up '__add__' 
from 2.__dict__ (it's there), then execute the function before you finally 
get to the "add" instruction.

So ultimately, you pay for he flexibility.  Sure, you can kind of optimize 
builtin operations (like "2+2"), but even with something like a 'PPU' (Python 
Processing Unit) that had hardware dictionary support (<5ish cycles per 
lookup) you'll still be an order of magnitude off C easily.


It's not hopeless though.  With an insanely clever JIT VM and lots of caching, 
it could be possible to get Python within an order of magnitude of C, but the 
demand isn't really there.  Things that need to be fast can be written easily 
enough in C libraries.

I think Pypy, which is an implementation of Python in Python, may be headed in 
that direction (clever JIT), but it's a long way off to say the least.






More information about the Python-list mailing list