Mailing List Archive

[Bruce Dodson]
> ...
> I also think that a python that has enough knowledge of types to
> perform inlining... well, such a beast is no longer Python, no matter
> how similar the syntax appears.

Simple inlining doesn't require any knowledge of types, and would be
valuable in many programs. The thing that stops it today is that you just
mever know what a name is bound *to*; e.g.,

def f(i):
return i

def g(i):
return i+1

def h(indices):
sum = SomeType()
for i in indices:
sum = sum + f(i) + g(i)
return sum

For all Python knows, the invocation of f, the invocation of g, the hidden
invocation of indices.__getitem__, and/or the invocation of f(i).__radd__ or
sum.__add__ or (sum + f(i)).__add__ or g(i).__radd__ may reach into the
module globals and change the bindings of "f", "g", or both, to anything at
all, or even to different things on each loop iteration.

This is great when you need it, but is likely of no use to 99.9999% of
runtime Python cycles. If John freezes the module bindings, the guts of the
loop can be mindlessly transformed into

sum = sum + i + (i+1)

regardless of types with no change in semantics, a major boost in speed,
and-- if done straightforwardly --a major loss of debugability when an add
raises an exception.

there-ain't-no-free-lunch-but-some-good-meals-are-cheap-ly y'rs - tim

Bruce Dodson schrieb in Nachricht ...
>Ni! I don't see the point of creating a variant of python that aims to be
>more efficient, but does so at the cost of taking away Python's most
>powerful optimization mechanism: external C modules.

Here, i agree with Bruce.
At the moment, it's common practice to accelerate a Python
program that's too slow by moving parts of it into homebrew
extension modules. Taking away this option would maybe
invalidate Viper as a means of optimization. It would be okay
with me, though, if you allow a different kind of extension
modules (a different interface to the extension module)-
if ViperC creates C code, i don't see a big problem with
that.

>I also think that a
>python that has enough knowledge of types to perform inlining... well, such
>a beast is no longer Python, no matter how similar the syntax appears.

In this case, i disagree with Bruce. Implementing a subset
of Pythons semantic possibilities and keeping the same syntax makes
sense in real life. Just try to write your production code in a less
wild fashion than usually, not changing bindings all over, and you'd have
a comfortable way of getting at more speed without rewriting as
much stuff as if you had to port it to C.

Dirk

On Thu, 12 Aug 1999 00:15:12 +0200, "Dirk-Ulrich Heise" <hei@adtranzsig.de> wrote:

>Bruce Dodson schrieb in Nachricht ...
>>Ni! I don't see the point of creating a variant of python that aims to be
>>more efficient, but does so at the cost of taking away Python's most
>>powerful optimization mechanism: external C modules.

The answer is simple: external C modules
may be the most powerful optimisation mechanism _at present_,
but with a compiler, that will no longer be true.

'foreign' modules will still be needed to add functionality
that cannot be implemented in Python, such as access to OS services.
However, if pure python can be compiled to efficient code,
there is no need to hassle with C modules just to get better performance.

>Here, i agree with Bruce.
>At the moment, it's common practice to accelerate a Python
>program that's too slow by moving parts of it into homebrew
>extension modules. Taking away this option would maybe
>invalidate Viper as a means of optimization.

Why? If you _kept_ the original python
source from which the C code is derived, then you
could just throw out the C code and use the Python code
again. If you didn't, you are in for trouble when the Python
C API is upgraded or changed, or you decide to mode
to JPython.

>It would be okay
>with me, though, if you allow a different kind of extension
>modules (a different interface to the extension module)-
>if ViperC creates C code, i don't see a big problem with
>that.

There will be at least one, or perhaps more,
ways of adding extensions, but the primary purpose of this
will be

a) for compatibility (not efficiency)
b) for adding new functionality that pure python cannot support

There is a secondary purpose in allowing foreign language extensions
for efficiency, when Python does not have the constructions to
allow the compiler to optimise the code (or it is simply too hard to
do so).

In these cases, modifying the compiler, or adding
extensions to the language, may prove a better option,
since it retains the 'pure language' approach. In these
cases backwards compatability is lost, but it is also
true whenever you write a C module, you are bound to
a particular C API and lose compatibility with JPython
and probably CPython 1.6 and 2.0 and 1.4, etc.

>In this case, i disagree with Bruce. Implementing a subset
>of Pythons semantic possibilities and keeping the same syntax makes
>sense in real life. Just try to write your production code in a less
>wild fashion than usually, not changing bindings all over, and you'd have
>a comfortable way of getting at more speed without rewriting as
>much stuff as if you had to port it to C.

Yes, that is the basic premise: you can use Python's
nice syntax, and get _efficient_ code, and if you are careful,
it will run on CPython, JPython, and Viper.

This is the kind of code that one should aim for
most of the time anyhow: if you really do use nasty tricks,
at least the use should be isolated, and the dependence
reasonably transparent.

John Max Skaller ph:61-2-96600850
mailto:skaller@maxtal.com.au 10/1 Toxteth Rd
http://www.maxtal.com.au/~skaller Glebe 2037 NSW AUSTRALIA