Python un-plugging the Interpreter

[John Nagle]

DillonCo wrote:
> 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 an
> add instruction that takes something like 1 cycle.  Very fast.  In python, it 
> translates (very) roughly to: ...

    Most of the time, though, all that flexibility isn't being used.
The idea of the type inference system compilers like Shed Skin
is to figure out when it's one of the simple cases.

    Many cases are easy.  If a smart compiler sees

	for i in range(n) :
	   ... # something

and there are no other assignments to "i", then it's clear that
"i" can be represented as an integer, without "boxing" into a
general object.  That's a big win.

    There are many other similar optimizations.  For example,
if a Python object is always referenced using the "obj.attr"
form, and never with "obj[str]" or "getattr" or "setattr",
you can represent it with fixed slots assigned at compile time,
and dispense with the hash mechanism for attribute lookup.

    The generality should be there if it's needed, but when
it's not, the excess baggage should be removed.  That's how
you get the performance of the language up.

    This doesn't require type declarations.  There are arguments
over whether type declarations would help optimization.  They
might make it easier, but they're not fundamentally necessary.

				John Nagle