[m-users.] Enable LCMC tail recursion optimization by default?

Dirk Ziegemeyer dirk at ziegemeyer.de
Wed Apr 20 19:06:01 AEST 2016


Hi, 

> So when the compiler itself compiled in grade hlc.gc, enabling
> last constructor modulo call leads to a 0.3% slowdown. That is
> barely measurable, and would be, I think, a reasonable price
> to pay to eliminate some (though not all) causes of stack exhaustion.
> 
> When the compiler is compiled in grade asm_fast.gc, the cost
> is higher: about a 2.1% slowdown. That is harder to justify
> imposing on everyone.

The key learning point for me as a Mercury beginner is:
1. To pay attention that code is tail-recursive in order to avoid stack overflows.
2. Code might look tail recursive but isn’t.
3. LCMC option might help but doesn’t seem to be activated for the library/list module. (see mercury/library/Mercury.options)

Take performance and robustness into account is probably just a typical part of the learning process. I didn’t care much about these things up to now and the stack overflow took me by surprise.

My workflow is to write simple predicates together with test cases and then plug them into my application. This works so well that I have not used the Mercury debugger yet.

I’m aware of the „dangerous“ predicates now and I can just work around them e.g. by making them tail recursive with LCMC or use list.foldl instead of list.map or append cords instead of lists.

I understand that enabling LCMC might increase robustness but has a negative impact on execution speed and executable size because it duplicates procedures.

The most important thing for me is to know the reasons for stack overflows and how to work around them. If the cost of enabling LCMC are too high, I can easily live with the status quo.

Dirk.


More information about the users mailing list