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" <mfl...@cs.utah.edu> To: "J. Ian Johnson" <i...@ccs.neu.edu> Cc: "dev" <dev@racket-lang.org>, "J. Ian Johnson" <i...@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" <mfl...@cs.utah.edu> > To: "J. Ian Johnson" <i...@ccs.neu.edu> > Cc: "dev" <dev@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 _________________________ Racket Developers list: http://lists.racket-lang.org/dev
