[mercury-users] Hints on Optimisation

[Fergus Henderson]

On 07-Oct-1999, Ralph Becket <rbeck at microsoft.com> wrote:
> I've read the papers that describe the various optimisations carried out
> by the compiler, but it's not clear to me when or how deeply they are
> applied.  I wonder if there are a few rules of thumb that could be used
> to help the programmer decide when a particular piece of code is optimal,
> wrt the compiler, or what the tradeoffs are when coding up an inner loop,
> say.

I'm not sure that there is much one can usefully say about this
_in general_.  It really depends on the optimizations in question.
The only general suggestions I can offer are that if you're concerned
about performance, then the following steps may help:

	- profile your code, with both memory profiling and time profiling

	- try reading the generated assembler or the generated C code

	- if you want to get an understanding of what high-level
	  optimizations the compiler performs, you can use the
	  compiler's `--dump-hlds codegen' option to dump a representation
	  of the compiler's high-level source representation after
	  optimizations but immediately before code generation.

> For example, one thing I frequently want to do is wrap bits of `state' up
> in some ADT, which typically means having something like a type with a
> single constructor with a number of fields.  What is a good heuristic for
> guessing when the compiler will `unbox' an instance of the ADT so one
> can `update' the fields of the instance without creating a new boxed version
> on the heap?

If there is only a single constructor with a single field, then the
compiler will not use a boxed representation.  But apart from that,
the compiler currently does not do any unboxing optimizations as such.
Basically the only time it will avoid creating a new boxed version on the
heap is when it can see that a construction is followed by a deconstruction
(and/or a switch), and that the newly boxed data is not used after that.
Of course a programmer would rarely write that directly,
but often this pattern can arise after inlining or specialization.
The compiler's deforestation optimization tries to specialize
constructions which are followed by calls to procedures whose body
is a switch.

-- 
Fergus Henderson <fjh at cs.mu.oz.au>  |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>  |  of excellence is a lethal habit"
PGP: finger fjh at 128.250.37.3        |     -- the last words of T. S. Garp.
--------------------------------------------------------------------------
mercury-users mailing list
post:  mercury-users at cs.mu.oz.au
administrative address: owner-mercury-users at cs.mu.oz.au
unsubscribe: Address: mercury-users-request at cs.mu.oz.au Message: unsubscribe
subscribe:   Address: mercury-users-request at cs.mu.oz.au Message: subscribe
--------------------------------------------------------------------------