Why I love python.
newsgroups at jhrothjr.com
Fri Aug 13 13:16:47 CEST 2004
"Nick Patavalis" <npat at efault.net> wrote in message
news:slrncho8m9.pfh.npat at gray.efault.net...
> On 2004-08-13, John Roth <newsgroups at jhrothjr.com> wrote:
> > "Nick Patavalis" <npat at efault.net> wrote in message
> > news:slrncho5aq.pfh.npat at gray.efault.net...
> >> On 2004-08-13, Michael Scarlett <bitshadow at yahoo.com> wrote:
> >> Python needs drastic performance improvement if it is to scrap-off the
> >> "scripting language" stigma.
> > More performance would be helpful. There are a number
> > of projects that are working toward that end, of which
> > the most visible is the PyPy project.
> >> The only way to get these improvements is
> >> making it possible for a python implementation
> >> to produce *efficient* *compiled* code.
> > I think there are lots of people that would dispute
> > you on that. Current Java environments run close
> > to C++ performance due to the JIT compilers
> > that are built into the runtimes.
> You 're right, I was maybe a bit too dogmatic on my point. But you
> must accept that JIT-compilers are, nevertheless, compilers! They may
> be more intelligent and more flexible than traditional "ahead of time"
> compilers, but still they are fundamentally compilers. Furthermore,
> for most cases, it might be possible for an AOT compiler to produce a
> "binary" that doesn't contain the compiler itself.
It's generally regarded as not worth doing, simply because
JITs might compile different code for each time through a
method if the signature changes dynamically.
> > Current JIT technology doesn't require pre-declaration of variable
> > types; it's perfectly happy to insert checks at appropriate points
> > so that it can reuse code when the object types don't change (which
> > they don't most of the time.)
> What you mean I guess, is that the first time a function is applied,
> it is compiled to native-code, and a signature for the application is
> generated. The next time, the application is checked against the
> signature and if they match, the existing code is used, otherwise the
> function is re-compiled (preserving the previously compiled one too,
> is some sort of "cache"). Or am I getting it wrong? Even in such a
> case though per-declarations would help.
Exactly, although the scope is smaller than a function - it has
to check other variables that the method might refer to.
Declarations don't help unless they can provide a solid
guarantee of the variable's type. If they can't, they're
useless because the JIT has to insert the type checking
> Do you happen to know of any efforts to build such "AOT"/"JIT"
> compilation/execution environments for Python?
That's part of the plan for PyPy.
More information about the Python-list