[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()
docutils.parsers.rst.states.struct.__init__
Raymond's generates:
JUMP_FORWARD 0
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