Cool! Nice that you did so extensive writeup on your encoding. Yes, it makes a big performance difference if do not have to allocate a new CpsFrame to start a tail call. I am guessing here, but I think the performance increase is not just because of GC, but also because it gives better data cache locality. In Erjang the CpsFrame structure you write about is inlined into the EProc process object which is passed around in all calls. Sometimes it would be great to be able to debug the code the JVM generates. Sigh.
Kresten On Dec 14, 4:22 am, Per Bothner <[email protected]> wrote: > On 12/08/2009 05:39 AM, Kresten Krab Thorup wrote: > > > FYI, I wrote a blob on how I encode tail recursion in Erjang: > >http://bit.ly/6XIma1. > > The "trampoline" mechanism you describe is basically what Kawa > does when in --full-tailcalls mode - the basic idea is of course > quite old. > > (I suspect Erland's parameter-passing is faster, as Kawa could > do with some tuning here. I've concentrated on the performance > of the default --no-full-tailcalls mode.) > > Kawa does support "state-machine semantics" where mutually recursive > functions are compiled to gotos, even when in the --no-full-tailcalls > mode. (This is fairly recent - it was implemented this Summer.) > > Rather than a single function per class, Kawa compiles multiple > functions to a class, which reduces static footprint, at the cost of an > extra level of indirection (but only when calling an unknown function). > > This link has a description of how Kawa implements functions, though it > is very sparse on how tail-call-elimination > works:http://www.gnu.org/software/kawa/internals/procedures.html > -- > --Per Bothner > [email protected] http://per.bothner.com/ -- You received this message because you are subscribed to the Google Groups "JVM Languages" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/jvm-languages?hl=en.
