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

[Markus Kohler]

Christian Tismer wrote:
> 
> 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.

Yes. Could it be that the problem is that  for the CALL_FUNCTION byte
code
call code_eval2 is called recursively ?


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

IMHO the 30% are not worth the code bloat most times. 

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

Markus
-- 
Markus Kohler  mailto:markus_kohler at hp.com