Psyco Specializing Compiler
Rigo Armin
"Psyco", the Python Specializing Compiler I introduced some time ago on the
python-dev mailing list, is beginning to work. Its goal is to accelerate
execution of any Python program by dynamically compiling several
"specialized" versions of your code directly in machine code. For more info
see
http://homepages.ulb.ac.be/~arigo/psyco/
Currently works on very simple examples only, but quite well: with an
acceleration factor of 100, including the compilation time! I expect a
factor of about 10 in compiling real code.
Python is known to be "impossible to compile". Psyco shows that it is only
half the story. True, Psyco does not statically compile your code, so don't
expect to turn a .py file into a stand-alone .exe file. This still requires
the full interpreter. But Python or any other interpreted language can
theoretically be run as fast as fully optimized C. If you don't believe it
wait for a full-featured Psyco. It won't be as fast as C but it will
probably be faster than you believed was possible :-)
Armin Rigo
Skip Montanaro
I took a quick look at your latest revision of Psyco this morning. Psycho,
indeed! I won't even pretend I understand python_eval*.h. I thought you
were looking at using GNU's Lightning package to generate code. It appears
you are directly generating raw Intel machine code at this point.
if-i-could-just-constrain-my-programming-to-ints-ly, y'rs,
--
Skip Montanaro (sk...@pobox.com)
http://www.mojam.com/
http://www.musi-cal.com/
Terry Reedy
"Rigo Armin" <ar...@belgacom.net> wrote in message
news:3bc4d2e4$0$36473$ba62...@news.skynet.be...
> Hello everybody,
>
> "Psyco", the Python Specializing Compiler I introduced some time ago
on the
> python-dev mailing list, is beginning to work. Its goal is to
accelerate
> execution of any Python program by dynamically compiling several
> "specialized" versions of your code directly in machine code. For
more info
> see
>
> http://homepages.ulb.ac.be/~arigo/psyco/
An interesting project. If I understand properly, you are dynamically
compiling small chunks of PyCode to machine code according to the
actual run-time type of the values involved in the chunk. Its a
little mind-bending at first, like metaclasses and Stackless.
You say that your system saves the compiled machine code for a
function, after the function exits, for later reuse. Are the saved
chunks tagged with the specific types used in the compilation, so the
the system will recompile a function if/when entered with different
types? (This would be something like C++ compiling alternate versions
of a template for different types.)
While aiming for completeness is good, speeding up just arithmetic
functions would be an important contribution. You might consider
making explicit assumptions that programmers using your system do not
pathologically rebind variables. For instance, tail recursion
elimination requires that the name of the recursing function not be
rebound to anything else during the recursion.
> Currently works on very simple examples only, but quite well: with
an
> acceleration factor of 100, including the compilation time! I expect
a
> factor of about 10 in compiling real code.
Do you have any actual numbers?
> Python is known to be "impossible to compile". Psyco shows that it
is only
> half the story. True, Psyco does not statically compile your code,
so don't
> expect to turn a .py file into a stand-alone .exe file. This still
requires
> the full interpreter. But Python or any other interpreted language
can
> theoretically be run as fast as fully optimized C. If you don't
believe it
> wait for a full-featured Psyco. It won't be as fast as C but it will
> probably be faster than you believed was possible :-)
>
> Armin Rigo
Terry J. Reedy
Armin Rigo
On Wed, 10 Oct 2001, Skip Montanaro wrote:
> were looking at using GNU's Lightning package to generate code. It appears
> you are directly generating raw Intel machine code at this point.
Yes, right. No more licensing problems. I finally decided that writing raw
machine code would not be too much of a hassle. I made experiments with
generating code that itself generates code... To do this kind of thing you
really need to know the machine encodings; I had to write a formal
description in a Python file of the most common Intel instructions (the
next releases will include this kind of stuff).
I am currently reorganizing the source to more closely match the
description given in the doc, keeping the actual code-producing macros
completely separate from the rest, to facilitate porting to other
processors. I am also considering enhancing the formal instruction
descriptions enough to let a Python script write the C macros
automatically from it; porting would then be a matter of formally
describing the encodings only.
Armin
Armin Rigo
On Thu, 11 Oct 2001, Terry Reedy wrote:
> An interesting project. If I understand properly, you are dynamically
> compiling small chunks of PyCode to machine code according to the
> actual run-time type of the values involved in the chunk.
That's only part of the story. The specialization can actually occur on
anything, not only on the type of the Python objects --- althought it will
probably be the most common case. An example of specialization over
something else would be when using constants; e.g. in code like 'x=1;
x+=2' the addition is performed at compile-time, because 'x+=2' can be
specialized for the only case that might occur, that is, when 'x' is
currently equal to '1'.
> You say that your system saves the compiled machine code for a
> function, after the function exits, for later reuse. Are the saved
> chunks tagged with the specific types used in the compilation, so the
> the system will recompile a function if/when entered with different
> types?
Yes, that's how we can think about it, althought more general than just on
types. For example in a function call, say 'f(x)', Psyco can use the
current specializations of 'x' to recompile 'f'. If we know that 'x', say,
is an int, look for a version of 'f' specialized for ints. If we know that
'x' is zero, 'f(x)' can be recompiled by knowing that the argument will be
exactly '0'. This means one of the big benefits of inlining in C --
constant folding -- is also available. Interestingly enough, we have this
benefit without the drawback of code explosion, because several calls to
'f(0)' can still call the same code. Removing the overhead of the 'call'
instruction itself could be done later, e.g. by tagging which blocks of
code are small and self-contained enough for inlining by copy.
> While aiming for completeness is good, speeding up just arithmetic
> functions would be an important contribution. You might consider
> making explicit assumptions that programmers using your system do not
> pathologically rebind variables. For instance, tail recursion
> elimination requires that the name of the recursing function not be
> rebound to anything else during the recursion.
I will certainly make such assumptions at first; for completeness,
pathological rebinds could be detected e.g. by enhancing dictionaries to
signal when they are modified, letting Psyco know that the compiled code
has become invalid. Such solutions would not slow down at all the
generated code in the common case. It would also let the value of global
constants be inlined; if a global variable's value changes later, we
invalidate the produced code and mark the variable as run-time instead of
compile-time-known.
Armin
Goh S H
Great works! you're moving Python into next level, just wonder when
can I use it in production, light-speed performance. Will it faster
then Java? or should I should ask will it faster than C/C++? :-)
Thanks & Regards,
Goh
Armin Steinhoff
Armin Rigo
On 11 Oct 2001, Goh S H wrote:
> Great works! you're moving Python into next level, just wonder when
> can I use it in production, light-speed performance. Will it faster
> then Java? or should I should ask will it faster than C/C++? :-)
It will certainly be slower than a good just-in-time compiler for Java
which can operate at much more than 50% of the speed of C. I think that we
can expect roughly one order of magnitude less than C. Currently Python is
two-three orders of magnitude below C. Introducing optimizing compiler
techniques into Psyco, maybe triggered by statistics measuring typical
usage, could one day give Java JIT speed or better.
For "faster than C/C++" there are theoretical techniques available (yes,
again, I guess you don't believe me but again, wait, it will be done one
day --- that's just a much more involved project than Psyco).
A bientot,
Armin.
aotto
if you wan't to have a look to a full working script "Compiler"
don't forget to visit:
http://www.compiler-factory.com
I know all the problems you have and all the problems you'll get
in the next 2-3 years of full time 6*12*52*3 = 11232 hours
working time. I hope you don't have done to many plan's for the
next years.
keep on trying
mfg
aotto :)
Skip Montanaro
aotto> if you wan't to have a look to a full working script "Compiler"
aotto> don't forget to visit:
...
Why do you keep posting teasers to this list? It appears you don't support
Python, and when I visited last time I saw no indication that you planned
to. In addition, your tools aren't open source, so it's unlikely they would
appeal to a broad subset of Python's user population.