The way to a faster python [was Python IS slow !]

[Christian Tismer]

Martijn Faassen wrote:
> 
> Markus Kohler wrote:
> 
> [how to speed up Python - interpreter optimizations and JIT]
> 
> I've been thinking about something else. I'm not quite sure how feasible
> this is, though. The idea goes something like this:
> 
> * Subset Python; make a strict subset so that any code written for the
> subset can still run in Python proper. Mainly remove some of the
> dynamism.

I like the idea, at first glance.

The hard thing is to define what must vanish and what must stay.
This all under the condition that Swallow becomes a true Python
subset, but nothing different. I'm not yet sure how that works.

> * Add static typing info; initially by hand though some type inference
> can always be added later:
...
> __types_printlist = { "mylist" : StaticTypes.list(StaticTypes.string),

Now about the implications:
Does StaticTypes imply that StaticTypes.list(StaticTypes.string)
will only allow "mylist" to be a list of strings?

How static is static?
What about global variables and their types?

Assuming you have a StaticTypes.function as a global,
would that guarantee that this is always the same function
with the same code, or is it static only in the context
of a class method or other function as a parameter?

I believe you want to fix all types and also to fix
all semantics of current objects to what it happens to
be the first time.

> * Now combine this with the static typing info, and generate C code. The
> idea is that the Swallow subset is limited enough so that very efficient
> C code can be generated. Of course quite a lot of static typing info for
> the standard library is also needed to complete the process.

I think the type info is nice to have (yet ugly to write),
but you don't need it.
Since you are restricting yourself to use always one type
(which I think is the right idea(TM)), the types need not
always be defined, but they can be collected by a single
standard Interpreter run. One just has to record the types
seen.
The type tracking code can be expressed by Python VM 
instructions which can be inserted into the compiled
standard code, so no parsing is necessary.

> * Also automatically generate interface C code for the places where the
> generated C code talks to Python proper and vice versa.
> 
> I know this is like Python2C, but with added static type info, and no
> attempt is made to translate all of Python; just a subset.

P2C could be used as a basis, but most of the generated
general calls into the API could now be expanded to
type specific versions.
Although I'm not on the side of C generators. Too much
code bloat.
I would prefer an efficient interpreting register machine
which calls the type specific code snippets instead
of mimicking the standard interpreter. This would
already give a massive speedup.

...
> Later on we can try to add type inferencing and automatic swallowing of
> portions of code that are deemed swallowable.

Can that be done without breaking language semantics?
Without complete program analysis, you can't even
tell wether None is really None or 42.

> Does Swallow seem useful to others? Any stumbling blocks that wreck this
> idea? I'd like to see some discussion; if people like the idea, perhaps
> we can even do some coding.

I still have the problem of "subset".
Python has dynamic namespaces. 
Swallow cannot, as far as I see it.
Let's assume that swallow has a known function to import
something, and we assume that import behaves like one would
expect (although that too cannot be guaranteed).
Whenever Swallow imports, it must rely on that the imported
code is swallowable. Since there are a number of dependencies
between the standard module, a single non-swallowable
module would break this rule.
This would mean that finally, Swallow can only rely on
builtin objects which are of quite fixed semantics.

Conclusion: Swallow must redefine almost all modules to
guarantee the assumed semantics, or it has to stay with
primitive types and has to avoid almost all imports.

Now, the subset is getting quite small, since Swallow
may only import swallowed code or builtins. Existing
modules must be swallowed by hand, or be proven to
allways work the same, whenever type resolution and
binding occours.

The other way round: Can python always import Swallow
modules? Only if Python's types behave as Swallow
expects. I fear this doesn't work with global
objects, or we get contradictions. The interface
can only be by some immutability and local copies,
no sharing of mutable objects is possible.

Maybe that I'm looking too much for problems?

anyway, interesting - chris

-- 
Christian Tismer             :^)   <mailto:tismer at appliedbiometrics.com>
Applied Biometrics GmbH      :     Have a break! Take a ride on Python's
Kaiserin-Augusta-Allee 101   :    *Starship* http://starship.python.net
10553 Berlin                 :     PGP key -> http://wwwkeys.pgp.net
PGP Fingerprint       E182 71C7 1A9D 66E9 9D15  D3CC D4D7 93E2 1FAE F6DF
     we're tired of banana software - shipped green, ripens at home