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

[Martijn Faassen]

Christian Tismer wrote:
> 
> Martijn Faassen wrote:

[snip]
[Christian describes problems with statically typed globals interacting
with Python]

Okay, let's remove globals from Swallow for now, then. :) Or make them
inaccessible to Python, perhaps.
 
> > > 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.
> 
> No, I meant functions as first class objects. Would you bind
> them statically, so they never change?

I thought I was talking about this too (but in C terms).

A function would get a static type, which is the type of its arguments
(and the amount of its arguments). The type of what it returns can be
included too (though we can get overloading problems that way so this
needs more thinking).
 
> > Do you fixing types to their state upon initialization? I.e.:
> >
> > i = 5
> 
> I thought so.
> 
> > Means i is of type integer forever? I was thinking of at first adding
> > all this info by hand, from the outside.
> 
> Well, if we must. But this looks so different from Python.

Sure, but the nice thing of these Swallow type declarations in a dict is
that the code is executable by Python too. It'll just ignore these
dicts. And of course later on we can make preprocessors that construct
these dicts automatically. Since you volunteered for automagical type
inference stuff (fixing the types at first assignment, basically), you
can make that preprocessor. :) Until then we cut this problem away from
Swallow, though.

[P2C, blode coat]
> 
> > 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. :)
> 
> Interpreting everything is as wrong as compiling everything.

That's why we keep Python proper, right?

> Optimization in its sense must be goal dependant. Things which
> have to be fast might be compiled and grow big. Things which
> have to be there should not.
> Just try to pour the whole Pyhton linbary through P2C.
> How large would the binary be. 5MB, 10MB?
> There cannot be a one principle fits all solution.

Right, but couldn't statically typed Swallow code be translated into
more straightforward C? (without lots of bloat) We're talking about
removing lots of the Python dynamism from Swallow, after all.

[snip efficient interpreting register machine discussion]

Of course there's no reason not to use something else (such as a fast
interpreter exploiting the type info) as a Swallow backend either.

> > > 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.
> 
> Would mean to have basic S-type things which are known
> to produce nothing else, and build everything from these.

Admittedly I'm still vague on all of this, but automatic translation of
suitable Python code to Swallow code might look like this:

* Determine if the Python code is within the Swallow subset. This should
be a simple parsing job. I hope. 

* If it isn't in the subset, complain and give up.

* If it is in the subset, we can assume a lot of things all of a sudden.
We do some automagic type inferencing, and then function gets swallowed.

The problem is the dynamism kicking in unexpectedly; for instance, it's
virtually impossible to determine what types arguments of functions are;
it may be something rather dynamic is passed into a function that is
Swallow parsable, turning the function into something more dynamic after
all. But I don't think we're in a dead end yet; possibilities seem to
exist.

[snip Python / Swallow interaction problems -- Python can talk to C and
vice versa, though]

> Yes, and you know how careful it has to be for that :-)
> If we write something for a couple of hackers who
> take every risk, just for the cycles, well.
> But as a true language subset, with the same
> promise of error handling and not core dumping,
> you need to consider quite much.

You're right. Wouldn't a layer that checks if types of Python objects
that are passed to Swallow are right be enough though? Although this
only works for basic objects, not for the real dynamic stuff (such as
objects made from classes). The same as you say, anyway.

Regards,

Martijn