Use Jython to make true executable?

[Michael Hudson]

On 10 Jun 2001, Carl Fink wrote:

> 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.
>

Congratulations, you have just missed the point!

To be fair, I probably wasn't all that clear.

What I was claiming (admittedly without proof) was that if you execute,
say,

    d['bob'] = 'bar'

for some dictionary d, a significant amount of the execution time is spent
by PyObject_SetItem figuring out that d is a dict, and so that
PyDict_SetItem should be called, and that this function has to work out
that 'bob' is a string, and so how it should compute it's hash & possibly
how to compare this to other keys in the dict, etc.  Speaking roughly;
this isn't exactly what goes on inside the interpreter.

There will also be the time it actually takes to insert an item into a
dict, and the time spent dispatching opcodes.  What I was trying to say is
that the dispatching opcodes time is only part of what makes Python slower
than C.  You can compile the methods as optimally as you like and
eliminate the opcode dispatch, and Python will stay slower.

Mind you, I don't know how Jython works, so maybe if you use gcj/Jython
you have already eliminated the opcode dispatch - and you still get slower
code (in general, obviously) than C.

Cheers,
M.