[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: Tailcalls. Was Re: Manual timeslicing the VM.
- From: Glenn Maynard <glenn@...>
- Date: Fri, 5 Aug 2005 14:41:21 -0400
On Fri, Aug 05, 2005 at 01:06:40PM -0500, Rici Lake wrote:
> On 5-Aug-05, at 12:53 PM, Glenn Maynard wrote:
> >Here, I was referring to self-recursion: it may make sense, when
> >to want to know which function kicked off a tight recursion, but in the
> >state machine case it feels wrong and unintuitive for a debugging
> >being asked "who called this function" to return the function that
> >the state machine originally.
> Does it? Would you want the debugging function to show you the 327,432
> previous states before you saw the function that originally created the
> maze? Would you want the state machine to fail because of stack
Personally, I don't care about that in C; I'd consider it very poor,
dangerous practice to write C code that *depends* on tail call optimizations
to work at all. C programmers have to trust the compiler to optimize, in
order to write sane code, but depending on a particular optimization to
function at all seems like a very bad idea. Code that did that would blow
up in a debugging (unoptimized) build. (It's acceptable in Lua, since tail
calls are explicitly defined as part of the language.)
In Lua, I don't expect to see the states--but I do want to be able to see
that stack frames are missing.
In C, in the general (non-recursive) case, it's a legitimate speed and stack
optimization, but from a "noise in the backtrace" perspective, I find that
it's "noise" that they're missing, since it's one more major optimizer-bomb
I have to watch out for in production bug reports. I can't think of any
reason to *want* those tail calls to be missing from stack traces.
> gcc can be instructed to not insert tailcalls; under some circumstances
> this is useful, although as the maze example illustrates it can lead to
> other bugs. Still, for those occasions, and for those who share your
> intuitions about state machines, it might be reasonable to have some
> mechanism in Lua for doing the same thing; the nontailcallable closure
> flag I suggested has the advantage of allowing some selectivity.
> (Suppose you use a library which unbeknownst to you is implemented with
> a tailcalled state machine; globally turning tail calls off might then
> make it impossible to debug your code because the library consistently
Er, debugging builds (-O0 -g) in gcc don't do tail call optimizations. Those
are turned on at -O2. A library that doesn't work below -O2 is a library
I'd keep my distance from. :)