How slow? (was Re: Python IS slow !)

[Christian Tismer]

Markus Kohler wrote:
> 
> M.-A. Lemburg wrote:
> >
> > Markus Kohler wrote:
> > >
> > > >>>>> "Gordon" == Gordon McMillan <gmcm at hypernet.com> writes:

[much deleted]

> > Have you tried the P2C "compiler" ?
> >
> >         http://lima.mudlib.org/~rassilon/p2c/
> 
> Yes, the speedup is not that great. As far as I can remember not more
> tham 30%.
> >From what quantify tells me it's still spending a lot of time in
> function calling code.

P2C does all it can do to get the interpreter overhead away.
For me this turns out as a nice try but the wrong idea.
These 30% generate a C code bloat of hundreds of kilobytes
of C code, while the internal function call overhead is still
there, eating probably at least as much.

If such code could be generated in memory on the fly, well
then I'd consider it. Perhaps we should provide a C compiler
as an optional extension module for a couple of platforms
and use it just for time critical cases.

Still there is the 30% limitation which makes me doubt
if it makes sense to us this approach at all. If we were
able to break the C API after certain objects are known,
and if we had access to some processable description of
their functionality at run time, then this limitation
could be overcome.
This is one advantage of JPython which has no internal
language barrier. A good JIT can optimize away, since
everything is Java machine code internally. And as I read
in the JPython list, with the latest compilers JPython
turns out to be slightly faster than CPython for some tests.

ciao - chris

-- 
Christian Tismer             :^)   <mailto:tismer at appliedbiometrics.com>
Applied Biometrics GmbH      :     Have a break! Take a ride on Python's
Kaiserin-Augusta-Allee 101   :    *Starship* http://starship.python.net
10553 Berlin                 :     PGP key -> http://wwwkeys.pgp.net
PGP Fingerprint       E182 71C7 1A9D 66E9 9D15  D3CC D4D7 93E2 1FAE F6DF
     we're tired of banana software - shipped green, ripens at home