[pypy-dev] Re: PyCON bits
mwh at python.net
Mon Mar 29 19:43:22 CEST 2004
Armin Rigo <arigo at tunes.org> writes:
> Mitchell Kapor's keynote (Using Python to Develop a Large-Scale Open Source
> Application: A Report from the Field): the two main points stressed by
> Mitchell is that Python needs (1) more performance and (2) more security.
> Looks familiar?
What does he actually mean by (2)?
> IronPython (Jim Hugunin): Python for .NET. Seems to be very fast, up to 40%
> better than CPython. The trick is to contrieve as much as possible (and
> more!) the Python semantics so that they fit into existing .NET built-in
> operations. .NET itself is then able to optimize them extremely agressively.
> The result is generally significantly faster than CPython.
> What we could learn from IronPython is how the common cases are speeded up by
> a lot of boilerplate "fast-path" code (i.e. there is a 8x8 table for calling a
> function with 0 to 7 arguments when the function expects 0 to 7 arguments).
Hmm. I wonder what memory consumption is like...
> The other thing we could learn is how to use .NET as a PyPy target platform,
> what the tricks and the main limitations are. But Jim doesn't release code
> before he thinks it is finished :-(
> Starkiller (Michael Salib): this is a purely static source-to-source
> Python-to-C++ translator, which does type inference. It works by analysing a
> graph which closely mirrors the Python source code. As expected, it has some
> trouble with the most dynamic features like exec/eval, but it is relatively
> advanced in some directions like OO. Some control structures (like 'for') are
> not implemented.
> Bob Ippolito came up with an incredibly cool idea: we can already generate
> control flow graphs, which give a low-level pre-processed version of a Python
> source; so we should just feed that into Starkiller, which would analyse it
> and translate it into C++. Starkiller shouldn't try to parse the source and
> analyse at the source syntax level -- we can do better with the control flow
> graphs. But we shouldn't try to reimplement type inference -- Starkiller does
> a better job at that. Starkiller is precisely the component we are missing in
> our translation project!
Sounds cool. Do you know how C++ specific it might be?
> Guido's keynote (Python 3000): some directions for the next major rewrite of
> Python. I have a rant against both issues in the language evolution that he
> talked about: a syntax for types, and much more iterators. As far as I can
> see, both are essentially a way to improve the performance and reduce the
> simplicity of the language. I'm ok with performance tricks that don't show up
> on the user, but not with the ones that require him to learn new ways of
> getting the job done when there is already one. Particularly when we have the
> theory to recover most of that performance automatically.
> """Q: Will python 3k be built in python?
> A: Ask Armin (Rigo) and Laura (Creighton). If they succeed it's possible for
> Pypy to be the base for Python 3K. Guido thinks it's about as likely as
> Python 3K being written on top of Parrot..."""
> Let's prove him wrong!
(who came as close to unsubscribing from python-dev as he's ever been today)
Lisp nearing the age of 50 is the most modern language out
there. GC, dynamic, reflective, the best OO model extant including
GFs, procedural macros, and the only thing old-fashioned about it
is that it is compiled and fast. -- Kenny Tilton, comp.lang.python
More information about the Pypy-dev