[racket-dev] Experiments with closure conversion

I mean the difference between a constant closure that takes an extra vector argument for the environment and a Racket closure that has its own environment representation.
Lightweight closure conversion and super-beta inlining both need a way to access surrounding environments for the shared bindings, so it would be nice to just use Racket's own closure-ref (or whathaveyou) to do that rather than change all affected functions to use a different calling convention with vectors.
-Ian
----- Original Message -----
From: "Matthew Flatt" <mflatt at cs.utah.edu>
To: "J. Ian Johnson" <ianj at ccs.neu.edu>
Cc: "dev" <dev at racket-lang.org>, "J. Ian Johnson" <ianj at ccs.neu.edu>
Sent: Friday, November 23, 2012 8:54:58 AM GMT -05:00 US/Canada Eastern
Subject: Re: [racket-dev] Experiments with closure conversion

Sorry --- I don't understand what you mean by "lightweight closures use
the same representation".

If you convert a `lambda' so that it doesn't capture any variables ---
perhaps because you moved formerly captured variables to a vector
argument --- then the compiler will compile it as a constant closure
(or a module-level closure if it captures only module-level bindings).

The compiler will not detect that a particular argument of a function
is always a vector, that the vector is always size N, that the vector
always contains the values of N variables, and therefore that the
vector argument can be replaced by N arguments to avoid constructing
the vector.

At Wed, 21 Nov 2012 13:03:06 -0500 (EST), "J. Ian Johnson" wrote:
> Your answer sounds like we're on the same page, so I'll follow up. Is there any 
> way to communicate with Racket's closure conversion so that lightweight 
> closures use the same representation? I would have to ensure that lightweight 
> closures never flow to functions that I myself don't have the ability to 
> transform to use the right calling convention.
> 
> Sharing is a separate optimization I am considering (Shao & Appel 2000)
> Thanks,
> -Ian
> ----- Original Message -----
> From: "Matthew Flatt" <mflatt at cs.utah.edu>
> To: "J. Ian Johnson" <ianj at ccs.neu.edu>
> Cc: "dev" <dev at racket-lang.org>
> Sent: Wednesday, November 21, 2012 12:56:09 PM GMT -05:00 US/Canada Eastern
> Subject: Re: [racket-dev] Experiments with closure conversion
> 
> I think I don't yet understand the question.
> 
> Are you wondering about what happens to performance of a Racket program
> when you convert the program's source before giving it to Racket? And
> you wonder specifically about performing lightweight closure conversion
> and how Racket will treat the converted program?
> 
> If so, since Racket has its own closure conversion, my guess is that
> manually managing your own conversions will perform less well. It seems
> possible, though, that you can convert a program so that it performs
> better by using vectors that effectively allow sharing among closures.
> 
> At Wed, 21 Nov 2012 11:56:11 -0500 (EST), "J. Ian Johnson" wrote:
> > I have a control-flow analysis of a subset of Racket that is similar to R4RS 
> > Scheme (only with immutability in the right places). In fact, I have many - 
> in 
> > order to compare different analyses' effectiveness and precision, I have a 
> > series of post-hoc analyses and program transformations I want to do.
> > 
> > One is lightweight closure conversion (Wand & Steckler 1996)
> > 
> > Is a source->source transform that uses immutable vectors for passed 
> > environments and unsafe references for variable lookups enough to get the 
> > Racket compiler to pick up on what I'm doing?
> > I'm really not quite sure which question to ask, since I haven't made my own 
> > higher-order language compiler top to bottom before, and don't know if there 
> > might be internal represenations that I'd need to use rather than user-level 
> > representations.
> > 
> > Thanks,
> > -Ian
> > _________________________
> >   Racket Developers list:
> >   http://lists.racket-lang.org/dev