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

[Christian Tismer]

Martijn Faassen wrote:

[history.clear()]

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

statically agreed.

...

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

No. Talking of Swallow code running inside of Python.
How do you prevent a malicious acces to an outside
global variable which is not treated static elsewhere?
If you want Swallow fastm then you will avoid any check
at all after the code is swallowed, so you must guarantee
this. Can't afford a foreign CPython thread to change my
global variable.

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

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

[types automagically fixed once]

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

No big problem if I can assume that any binding to a type
will never change. Otherwise I would raise SwallownessError.

[P2C]

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

the code is simply so huge that I don't use it.
10 times faster, yes. But not for 30 percent.

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

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

I could talk very much about that. Please not today.
Well, a couple of words:
Think of a not so large number of working horse
functions which can manipulate certain Python objects,
given that their types are known.
Then build a register machine which efficiently
calls these functions. Quite similar to a Java VM,
but optimized with another goal in mind.

This is not as fast as C, but can be generated
by Python itself, and it's portable.


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

...

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

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.

> 
...

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

Right. Mutables are simply not compatible without
breaking rules.
But this is not so much of speed loss as it seems.
A swallow function doesn't need much globals.
It suffices to ensure that an object never can be
modified by CPython, when a Swallow function uses it.

good night - 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