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

[Martijn Faassen]

Christian Tismer wrote:
> 
> 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.

Thanks!

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

It's essentail though; by keeping it a strict subset we can continue to
use the current Python interpreter(s) for a rapid development cycle.

> > * 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?

Yes, that was the idea of StaticTypes.list(StaticTypes.string).. a sort
of generic constructor of a list of strings. For basic but strict
typechecking this would be necessary, I think. We can think of adding
more liberal types later.

> How static is static?

My idea was very static, mostly for simplicity. I don't know if it's
really simple, but I was thinking of just assigning a type to
everything, and do no automatic conversions. Those can be added later,
but it might complicate matters right now.

> What about global variables and their types?

You'd give those static types too in Swallow.

> 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'm trying to understand the question; are you talking about passing
along functions? I hadn't thought of static function signatures yet. If
you do static typing of functions, I imagine a function variable can
refer to any implementation with that signature.
 
> 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.

Do you fixing types to their state upon initialization? I.e.:

i = 5

Means i is of type integer forever? I was thinking of at first adding
all this info by hand, from the outside.
 
> > * 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.

Possibly, but with it could get complex. Of what types would list be? My
idea was to look at adding such type inference after you get the basic
system going (where types are added by hand).

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

Okay, you get to do the type inference part of Swallow. ;)
 
> > * 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,

I haven't looked at it in detail, so forgive me if I'm mistaken, but it
looks like it tries to do a straightforward translation of Python code
to C directly, without doing much parsing. Perhaps that cannot be
adapted easily to static types...

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

Naively I'd think code bloat could be fairly limited? Most of a Python
subset sounds like it could be expressed in C fairly easily. But I'm
sure I'm deluded here. :)

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

Could you explain this idea further?

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

I don't imagine one can add type inferencing of all code, but perhaps in
a limited subset one can? Would it be possible to automatically
determine if a section of code (a class, a def, a module?) is indeed
within the Swallow subset of Python (minus automatic type info)? If so,
then one could do automatic Swallowing.

Of course, I'm waving my hands around a lot here, never specifying
*what* the Swallow subset of Python in fact is. ;)
 
> > 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.

Right, doesn't sound like it.

[snip problems of Swallow code using Python code]

This was an area I hadn't thought about much yet; it indeed would seem
to be a problem. Perhaps some fairly transparant wrappers can be
supplied that fix some of this, however. After all, C code can talk to
Python.
 
> 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.

There'd be some limitations, but Python talking to Swallow code would be
similar to Python talking to C code. Hopefully with a lot of automatic
wrapping going on that takes away most of the problems.

The Swallow <--> Python interfaces aren't going to be very fast, I
expect, but I'd think the speed gains would offset the speed loss of the
interface code (after all that code is there now when interfacing with
C).

> Maybe that I'm looking too much for problems?

I'm sure there *are* problems, no need to look hard for them. ;)

> anyway, interesting - chris

Agreed, thanks for your response!

Regards,

Martijn