[m-dev.] status of --deep-profile-tail-recursion
Zoltan Somogyi
zoltan.somogyi at runbox.com
Tue Mar 31 17:27:03 AEDT 2015
On Tue, 31 Mar 2015 16:39:31 +1100 (AEDT), Julien Fischer <jfischer at opturion.com> wrote:
> The current situation where --deep-profile-tail-recursion is enabled by
> default and --deep-profile-tail-recursion is not enabled by default is
> not ideal, and also contrary to what the user's guide currently says,
> namely:
>
> With deep profiling, there are other modifications as well, the most
> important impact of which is the loss of tail-recursion for groups of
> mutually tail-recursive predicates (self-tail-recursive predicates stay
> tail-recursive).
>
> Assuming that --deep-profile-tail-recursion *is* working (I will look
> into this as I happen to be profiling stuff at the moment anyway), are
> there any objections to switching the default values of these two
> options?
The thing is, deep profiling tail recursion is not as useful as it may appear,
which of course I found out the hard way. It has significant overheads,
and enabling it did not result in meaningful speedups. It does reduce stack
usage, but only for self-recursive predicates. Since it does not reduce
stack usage for mutually recursive predicates, you can still run out of
stack in a deep prof grade, and if I recall correctly, that used to happen
regularly to me when I forgot to set MERCURY_OPTIONS to avoid this.
(Several compiler tasks that operate on large data structures are
implemented using mutually recursive predicates.)
I think a better fix is to tie the grades that break tail call optimization
(which include the debug grades as well as the deep prof grades) to
the use of stack segments, and to fix the above quote in the user guide.
Zoltan.
More information about the developers
mailing list