[mercury-users] Structure reuse

Simon Taylor stayl at cs.mu.OZ.AU
Tue Jul 15 19:41:21 AEST 2003

On 15-Jul-2003, Nancy Mazur <Nancy.Mazur at cs.kuleuven.ac.be> wrote:
> >>It would be nice to be able to write code like this and have the compiler
> >>determine that it can update the tree in-place, eliminating unnecessary
> >>copying and memory allocation, improving locality, reducing memory usage
> >>and so on. I have no idea whether that is feasible though, or whether it 
> >>would require assistance from the programmer by specifying unique modes 
> >>or something like that.
> >
> >In practice, if you want to be sure that the optimization takes place
> >you'll need to specify unique modes (sorry, not working yet) rather
> >than relying on automagic compiler analyses.  Relying on the compiler
> >to do the work will result in difficult to track down performance bugs
> >where a data structure which should be single threaded actually isn't.
> Even if you let the programmer annotate unique modes by hand, I thought 
> the philosophy of the Mercury compiler was always not to trust the 
> programmer, and therefore an automatic verification of these annotations 
> should still be done.

That's right, so if the data structure isn't used in a single-threaded
way, the compiler will report an error showing where. If you leave it all
up to the compiler, you're on your own if the reuse doesn't happen.

> But some cooperation human-compiler is interesting: let the compiler 
> deduce automatically the reuse, let the programmer indicate some hints 
> where reuse should be possible according to him, and then provide the 
> adequate feedback if the two views do not match.

That's what unique modes are for.

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

More information about the users mailing list