The way to a faster python [was Python IS slow !]

Vladimir Marangozov Vladimir.Marangozov at inrialpes.fr
Tue May 4 10:59:14 EDT 1999


Markus Kohler wrote:
> 
> Hi all,
> I would like to give you a summary of what I think would be the
> way to go to get a faster python ( and world domination ;-) ).
> Also I don't know if everything is feasible because I haven't looked
> into python's interpreter loop in detail it seems to me It should be
> possible, given that Smalltalk is probably as dynamic as python.
> 
> 1. One can use a dispatch table instead of a case statement by using
> an extension of gnu C. 
> ...

Highly compiler specific topic, classified as micro-optimization.
Take a look at http://sirac.inrialpes.fr/~marangoz/python/threaded_code/
I've done this for a previous version of Python and AFAICT the speedup was
negligible. You could easily adapt the code for the latest Python release
and time the result youself though. BTW, note that usually a big switch
statement in C is translated by the compiler into a jump table (i.e.
the result is indirect threading, augmented perhaps by some range checks
on the switch'ed value).

> 
> 2. Implement a method cache. For Squeak as far as I can remember this
> improved message sending performance by about 30%.

There was work done in this area, presented at the last Python Conference.
The results seem to be controversial. Except saving some dictionary
lookups (which are already very fast), this implies radical changes in
the core, reserved for Python2.

> 
> 3. Implement a Just in time compiler that compiles to threaded code.
> ...

Designing a good JIT compiler takes a lot of man/months and requires
support for several platform-specific code emitters. Although it could
give noticeable speedup, I don't see who's going to engage in this area,
at least in the near future :-)

> 
> Up to here the interpreter would be still fairly portable. It would compile
> out of the box for all platforms that gcc runs on.

Guido is reluctant to see Python bound to one compiler :-) I for one am
against this too. For example, on AIX gcc with max optimization flags produces
slower code than IBM's compiler. The latter is kept more closely up to date
with the architectures AIX is running on (insn sets, internal caches, etc).
This applies to other platforms as well.

> 
> 4. Implement a native just in time compiler producing machine code
> based on 3.

Yes, the key verb here is "implement"...

-- 
       Vladimir MARANGOZOV          | Vladimir.Marangozov at inrialpes.fr
http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252




More information about the Python-list mailing list