From: markus_kohler at hp.com (Markus Kohler)
Date: Tue, 4 May 1999 13:21:54 GMT
Subject: How slow? (was Re: Python IS slow !)
References: <m3eml0s7t2.fsf_-_@solo.david-steuber.com>
			<1286467371-87168848@hypernet.com>
			<p590b5ktld.fsf@bidra241.bbn.hp.com>
			<372ED403.1EECB02B@lemburg.com> <372ED5B6.2DE0C9A2@hp.com> <372EEF20.16744BF2@appliedbiometrics.com>
Message-ID: <372EF472.E4CA47BE@hp.com>
Content-Length: 1888
X-UID: 1977                                                 

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




