Why I love python.

[Nick Patavalis]

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.

Yes, I know about PyPy, and I think what they are trying to do is
write Python itself in a Python-subset that can be efficiently
compiled, or something along these lines. This is interesting (to say
the least).

>
> As far as I'm aware, the biggest current performance
> sink is function and method call overhead [...]
>
> Another thing to notice is the garbage collection
> algorithm [...]

Both very true!

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

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

Do you happen to know of any efforts to build such "AOT"/"JIT"
compilation/execution environments for Python?

Regards
/npat