Path: utzoo!attcan!uunet!yale!Krulwich-Bruce From: Krulwich-Bruce@cs.yale.edu (Bruce Krulwich) Newsgroups: comp.lang.scheme Subject: Re: dynamic compilation for scheme, with inlining, etc? Message-ID: <38554@yale-celray.yale.UUCP> Date: 22 Sep 88 17:56:36 GMT References: <8809142159.AA28551@uicbert.eecs.uic.edu> <327@scaup.cl.cam.ac.uk> Sender: root@yale.UUCP Reply-To: Krulwich-Bruce@cs.yale.edu (Bruce Krulwich) Organization: Computer Science, Yale University, New Haven, CT 06520-2158 Lines: 50 In-reply-to: adg@cl.cam.ac.uk (Andy Gordon) In article <327@scaup.cl.cam.ac.uk>, adg@cl (Andy Gordon) writes: >In article <8809142159.AA28551@uicbert.eecs.uic.edu> >wilson@uicbert.eecs.uic.EDU (Paul Wilson) writes: >>I've been thinking about using dynamic compilation for Scheme, >>and wondering if anybody else is. Have people abandoned the idea >>of dynamic compilation, and if so, was it premature? > >Firstly, by "dynamic compilation" I understand a system that >represents a programme to start with as a syntax tree or some other form >suitable for interpretation, but compiles parts of it into native code >as execution proceeds. Interpreted code is generally smaller than compiled >code so less space is needed than compiling the whole thing. I think you're overlooking several possible program transformations that could be done in addition to straightforward compilation, such as: (1) Inlining functions and de-inlining them when necessary (2) Different levels of compiled-code optimization (3) Caching of results (4) Special case handling of parameters by type (5) Analysis of memory use to reduce garbage generation (6) Dynamic analysis of ordering of comparisons >There appear to be two reasons for hybrid systems: (1) to give a variable >time/space tradeoff, i.e., between fast/bulky native code and slow/lean >interpreted code; (2) to allow fancy interpretive debuggers and tracers >in the presence of native code. > >I don't think reason (1) is very compelling these days, because the size of >compiled code is not an issue with today's computers---certainly, big ML >programmes that are compiled to native code by one of the production compilers >don't take up inordinate space. As I said above, I would bet that this does become an issue when more possible transformations are considered. >However, reason (2) is still attractive, because interpreted code will always >be easier to debug than compiled code. A dynamic hybrid system is all the >work of a static one, and more, so for it to be worthwhile it must make >debugging much easier. One can imagine a debugger threading through a >programme, seeking to use interpreted versions of compiled functions as it >finds them---maybe you could keep a pointer in each compiled function to an >interpreted version or the source. I'd be interested to hear how you get on. This is a good point. Similar uses might be the ability to redefine a component of a function without recompiling the entire function, or the ability to optimize only the inner loops of a function, Bruce Krulwich