Happy New Year, Dethe! Thank you for your interest. You write:
>PyPy uses a similar approach to Pyrex, called Psyco, which compiles
>directly to 80x86 machine code (Pyrex compiles to cross-platform C
>code). This allows PyPy to attempt to be faster than C-Python by
>creating compiler optimizations. Not sure what the PyPy story is for
>non-x86 platforms. There is also a project to recreate Python on top
>of Smalltalk, by L. Peter Deutch, which he expects to be faster than
>C-Python (and if anyone can do it, he could).
>Nice to see y'all again. Happy New Year (or Gnu Year?).
>--Dethe
I'd like to clarify a few misunderstandings I think you have. Psyco is
not a technique, but rather a specialising compiler available as a
Python extension module. It compiles directly to 386 machine
code. PyPy, on the other hand, currently emits cross-platform C
code. Our previous version emitted Pyrex code. Some people in Korea
are making a version that emits Lisp code. PyPy doesn't use Psyco,
though many ideas are common to both.
What's more there is nothing magic about machine code that makes it
automatically fast -- an inefficiently-coded algorithm in assembler is
still a turtle. The win in using PyPy is not about 'saving the time it
takes to have a conversation with your C compiler', but instead about
making such conversations more productive and useful. The more
information you can tell your C compiler about your data, the better
code it is prepared to generate. This is the tradeoff between
flexibility and speed.
When your Python system sees x = a + b it has no clue as to what types
a and b are. They could be anything. This 'being ready to handle
everything' has a large performance penalty. The runtime system has to
do be prepared to do a _lot_, so it has to be fairly intelligent. All
this intelligence is in the form of code instructions, and there are a
lot of them that the runtime system has to execute, every time it
wants to do anything at all. On the other hand, at code _reading_
time, the Python interpreter is purposely stupid-but-straightforward.
It doesn't have much to do, and so can be relatively quick about not doing
it.
A statically-typed compiled language works in precisely the other
way. When the runtime system of a statically typed language sees x = a+ b,
it already knows all about x, a and b and their types. All the
hard work was done in the compiling phase. There is very little left
to worry about -- you might get an overflow exception or something --
but as an oversimplification, all the runtime system of a statically
typed langauge has to know how to do is how to load and run. That's
fast.
So, one way you could speed up Python is to add type declarations,
thus simplifying the life of the runtime system. This proposed
solution is more than a little drastic for those of us who like duck
typing, signature based polymorphism, and the particular way coding in
Python makes you think and feel.
The PyPy alternative is to make the interpreter even smarter, and a
whole lot better at remembering what it does. For instance, when it
sees x = a + b instead of just adding this particular int to this
other particular int, it could generate some general purpose code for
adding ints to ints. This code could be thus used for all ints that
you wish to add this way. So while the first time is slow, the _next_
time will be a lot faster. And that is where the performance speedup
happens -- in code where the same lines get run again, and again, and
again. If all you have is a mainline where each line of code gets
executed once, then we won't help you at all.
Psyco is about as far as you can get with this approach and be left
with a module you can import and use with regular python 2.2 or
better. See: http://psyco.sourceforge.net/
PyPy is what you get when you pitch the old interpreter and write your
own. See: http://codespeak.net/pypy/
And we should probably move further disussion to pypy-dev, here:
http://codespeak.net/mailman/listinfo/pypy-dev
Thanks for your interest,
and thanks for writing,
Laura Creighton (for PyPy)
_______________________________________________
Edu-sig mailing list
[email protected]
http://mail.python.org/mailman/listinfo/edu-sig
