[Python-Dev] Re: The Other Py2.4 issue?

Delaney, Timothy C (Timothy) tdelaney at avaya.com
Mon Dec 13 01:11:47 CET 2004

Adam Bark wrote:

> Now this might sound a bit stupid but I've only been programming in
> python for about 6 months and before that about the same on VB. Anyway
> here goes, as python is built in C & C++ surely every piece of python
> code has a corresponding piece of C/C++ albeit more complex. So would
> it be possible to somehow make a program to convert the Python to C &
> C++ which can then be compiled with a C/C++ compiler.

Yes. And it would run at about the same speed as CPython.

The only way to significantly improve this is to remove much of the
dynamism of Python. As an example, I've been playing around with
Raymond's constant binding - making it do more aggressive binding (I'll
give an example later). By binding constants, I'm able to reduce the
runtimes for psyco-compiled versions of friendly code (lots of things
that can be converted into constant references) from around 2 seconds to
less than 0.001 seconds.

That's a very significant speedup. Unfortunately, it doesn't translate
as well into real-world code - or even benchmarks (parrotbench for
example gets a slight speedup but it's not overly significant).

As a quick example if the changes I'm playing with, 

    def func()

Raymond's generates:

    LOAD_CONST    (docutils)
    LOAD_ATTR     (parsers)
    LOAD_ATTR     (rst)
    LOAD_ATTR     (states)
    LOAD_ATTR     (struct)
    LOAD_ATTR     (__init__)

Mine generates

     0 JUMP_ABSOLUTE  15
     3 NOP
     4 NOP
     5 NOP
     6 NOP
     7 NOP
     8 NOP
     9 NOP
    10 NOP
    11 NOP
    12 NOP
    13 NOP
    14 NOP
    15 LOAD_CONST     (<unbound method Struct.__init__)

I've also been doing some peephole optimisations - the above actually
ends up being an immediate jump to the return bytecode, but that's
fairly useless. Using JUMP_ABSOLUTE instead of JUMP_FORWARD simplifies
doing this.

Once I've got the code into a fit state I'll send it to you if you're
interested Raymond ...

Tim Delaney

More information about the Python-Dev mailing list