freenode/#sicl - IRC Chatlog
Search
19:01:39
mseddon
gah, there was some retrospective about the orbit compiler's closure analysis (specifically about the assignment of 'environment strategies', that determined some bits were way over engineered), but I can't remember it- anyone have any ideas?
19:10:26
mseddon
though I'm happy to take any modern treatment of performant closure representations that's < 30 years old, of course.
19:12:51
mseddon
(with a view to e.g. stack allocate where necessary, chaining, vs copying cells across different closures, based on expected lifetime of the closure and deref cost, which I think is probably higher these days, since derefs are a lot more cache nasty than a nearly cache-less 68k)
19:21:12
mseddon
karlosz: so- copy the box of my outer lexical closures and just index directly, rather than chaining?
19:22:07
mseddon
and that pointless huge value that is referenced in the immediate subsuming closure that dies instantly hangs around
19:22:11
karlosz
if you don't, you won't be able to elide closure allocation for local functions who have all their call sites known
19:22:35
mseddon
sure. so actually the brute force method opens up better optimisations too, since we automatically de-trace garbage by not copying it.
19:22:36
karlosz
i mean, if you don't separate environment analysis from closure conversion, that is
19:23:03
mseddon
yes, naturally. and i am doing the latter atm, thinking about what i need for the former.
19:24:19
karlosz
now that you have the environments of what you need to close over for every function, then you just see if all uses of the function are at known call sites and oyu pick a strategy to represent the environment
19:28:45
mseddon
my source language is strict evaluated lambda calculus with a store. It has environments built in, so does js, so for that target I don't need to remove that feature from the source language.
19:30:45
mseddon
It makes sense though, no block in lisp really has THAT many things to think about, outside of the toplevel environment.