78 lines
2.9 KiB
Plaintext
78 lines
2.9 KiB
Plaintext
From: faassen at pop.vet.uu.nl (Martijn Faassen)
|
|
Date: Wed, 19 May 1999 10:50:45 +0200
|
|
Subject: Bytecode optimisation
|
|
References: <7hq7qc$itn$1@news.tamu.edu> <m3k8u6aj7i.fsf@atrus.jesus.cam.ac.uk> <7hsqim$8kr$1@news.tamu.edu> <37420CBD.FF15564@appliedbiometrics.com> <7ht6g1$rn0$1@news.tamu.edu> <37426993.D952585B@home.com>
|
|
Message-ID: <37427B65.BBA6A970@pop.vet.uu.nl>
|
|
Content-Length: 2562
|
|
X-UID: 1879
|
|
|
|
Jim Meier wrote:
|
|
|
|
> The thread on "swallow" seems to have dried up; maybe they've gone out to
|
|
> experiment with it?
|
|
|
|
I haven't *exactly* experimented yet, though I'm thinking about the C
|
|
generating part of Swallow now. Basically Swallow (internally) could
|
|
look like this:
|
|
|
|
Python code (in Swallow subset) + Static type info (for instance in
|
|
dicts) ->
|
|
Python parse tree with type annotations (error if type annotations are
|
|
missing or conflicting).
|
|
|
|
Now, from that Python parse tree with type annotations (in fact a
|
|
Swallow parse tree) we need to go to a 'parse' tree that can generate C
|
|
code. Note that the C tree doesn't have to be able to generate any
|
|
construct possible in C, just the parts necessary for Swallow.
|
|
|
|
I think the tricky parts are adding the type info to Swallow parse tree
|
|
(along with the type info for lots of builtin stuff), and then turning
|
|
this tree into the C tree.
|
|
|
|
Perhaps someone already has a python module that can generate C code
|
|
from some tree structure?
|
|
|
|
Random note: I think we need a form of C++ templates or generic
|
|
classes/types in order to do enough of Swallow. For instance, we need a
|
|
list(integer) and list(float) and list(fooClass). Some system of generic
|
|
programming seems necessary here.
|
|
|
|
> In any case, these ideas and the ideas from that thread are
|
|
> butting head-on. If a satisfactory way of finding "static" functions and
|
|
> type-constant variables, then that markup could be used both to optimise the
|
|
> python byte-codes and to generate native code directly.
|
|
|
|
Swallow in my view initially depends on manually adding this static type
|
|
info (and then Swallow assumes it's correct!).
|
|
|
|
> Depending on the speed
|
|
> of the system and how often the optomisation is done, this could be done
|
|
> automatically in the interpreter.
|
|
|
|
Not if you have to add static type info manually. Of course type
|
|
inference engines can always be added to Swallow later. :)
|
|
|
|
> It may be nescessary to keep two or more copies of a function around (if you
|
|
> want both speed and flexibility).. one optimized to flash powder in native
|
|
> code, one in the original python bytecode.
|
|
|
|
Yes, I had the same idea.
|
|
|
|
> When doing it's lookups, a quick
|
|
> second check for a) known types and b) if the types are known, then if they
|
|
> match the types assumed in the optimisation. If the check passes, it runs the
|
|
> optimised version. If not, it runs the standard version.
|
|
>
|
|
> (this might mean that only "swallowed" code can call other "swallowed" code
|
|
> without wrappers. I don't think this is a big deal?)
|
|
|
|
No, this sounds like a good idea.
|
|
|
|
Regards,
|
|
|
|
Martijn
|
|
|
|
|
|
|
|
|