new ideas?

John Roth johnroth at ameritech.net
Thu May 24 20:22:57 EDT 2001


"Joshua Marshall" <jmarshal at mathworks.com> wrote in message
news:9ejese$pr5$1 at news.mathworks.com...
> Jan Veleta <jan.veleta at pvt.cz> wrote:
> > I have found article about some programming language I never heard of.
> > I is called Standard ML, and one of the things which attracted my
attention
> > was
> > that it uses garbage collector while using machine generated code.
>
> > It's syntax is obviously far from python, but maybe some of compiler
gurus
> > may take a look at it, as it can bring some new ideas into python world.
>
> > Maybe it can help even in moving on compiled form of python.
>
> SML's a great language, but these ideas aren't too new.  Compilers for
> Common Lisp (eg.) have been doing this for a while.  My impression is
> that compilers aren't available for Python primarily because nobody's
> put the effort into it.
>
> Also of note is that SML is a statically-typed language, making
> compilation easier.  (Although this doesn't help things from a GC
> point-of-view.)

I would expect to be disappointed in a Python compiler. The reason is
simple: compiled languages are supposed to be fast, but the more
dynamism in a language, the more process time goes into the
operations, and the less goes into the interpreter. If you look at typical
compiled languages, you will find that the efficient parts are the
statically typed stuff - an int is an int, not an object that has to
be dynamically allocated, dispatched and garbage collected. In a
statically typed language, A = B + C can frequently be put into
three or four machine instructions (depending on the architecture). If
you can't depend on a specific name being an int, each and every time,
then you have to generate expensive method calls, etc.

Of course, there are dynamic type determination strategies, etc, but
you're never going to get the raw performance out of compiled Python
that you'd get if you just broke down and put the slow parts in C (or
Assembler, if you're really in a bind, or doing the next great push the
edge shootem up graphic game.

Guido seems to have done a very good job at wringing excess
overhead out of the interpreter. As the optimization people say, the
first thing you look at is choice of algorithm. Only then do you worry
about recoding it in a faster language - that is only going to get you
a linear speedup.

John Roth





More information about the Python-list mailing list