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