Use Jython to make true executable?

[John Roth]

"Carl Fink" <carlf at panix.com> wrote in message
news:slrn9i7bnv.o9r.carlf at panix2.panix.com...
> In article <m3bsnwv2p4.fsf at atrus.jesus.cam.ac.uk>, Michael Hudson wrote:
>
> > This is very unlikely to speed things up as much as you expect.  I've
> > never produced accurate numbers, but I'm fairly sure Python's runtime
> > is dominated by locating applicable methods, not the dispatch loop in
> > ceval.c.  If you could analyse a program sufficently to compute (some
> > of) these methods at compile time, *then* you might start to see a
> > real speed up (especially if this let you unbox some integers &
> > floats).
>
> Yeah, but Jython/gcc wouldn't involve ceval.c at all, would it?  I
> mean, presumably gcc would compile the methods themselves, and in an
> optimized manner.

Unfortunately, this is an essentially impossible problem. Note I said
"essentially,"
not "absolutely." The essence is that anything you say in Python, even if
it's as simple
as "a = b + c" involves uncertainty at --run time-- about what you mean. If
b and c
are integers, then it means one thing. If they are floats, then it means
something else.
If they are strings, it means a third thing. If they are some kind of user
defined objects
that have overloaded "+" then hopefully the object knows what it means - the
interpreter sure doesn't.

If you could give the compiler a clue, say something like "a and b are
integers that
will never exceed the hardware definition of maxint," then a compiler would
have
something it could generate efficient code for. As it is, a compiled Python
program
would essentially be a long series of function calls to the same functions
that the
byte codes invoke. As Michael Hudson has commented, exactly how much this
would squeeze out of run time is currently unknown, but it's unlikely to be
major.

In addition, I would think that a compiler could only optimize certain
things, such as
integer and floating arithmetic, method and function lookups, and a couple
of more
esoteric things. Strings and collection types, as well as much of the more
interesting
esoteric dynamic behavior will still require library functions.

John Roth
> --
> Carl Fink carlf at dm.net