[m-dev.] Equality and pointer equality

Peter Ross pro at missioncriticalit.com
Tue Oct 12 18:36:58 AEST 2004


Zoltan Somogyi wrote:

>On 12-Oct-2004, Peter Ross <pro at missioncriticalit.com> wrote:
>  
>
>>>It may be cute, but it wouldn't work, because it would break any promises
>>>of uniqueness.
>>>      
>>>
>>But wouldn't be able to work out when it is safe to do this by using the 
>>mode system, and calling a version of the unification predicate which 
>>did this only when it was safe to do so?
>>    
>>
>
>Only if you specialized the code of all the type-specific unify predicates
>to the precise mix of types and uniqueness annotations at hand. The cost
>in code size would be quite big. (Right now, those predicate are rough 10% of
>code size; with the specializations required, it would be 30-50%.) And even
>then, there is the problem that the unify predicates, like all other
>predicates, have their arguments passed by value. You can't change the
>input variables unless you change the parameter passing convention to call
>by reference or call by copy/return, and both of those have significant
>negative performance impacts. I strongly doubt the overall performance
>impact would be positive.
>  
>
I see your point about code explosion, but by the same token, nearly 
every mercury program that I've ever written only uses the following 
input modes: di and in.  Thus if we just specialised for these two cases 
we would catch most cases.

The problem of changing the parameter passing convention could be 
avoided by only doing the replacement of pointers inside the term (which 
is what I think Ralph suggested in an earlier email), ie the outer-most 
constructor would still be unique.

I don't know if this optimization would improve, worsen, or have no 
effect on the performance, I'm just thinking out loud at the moment. 

I don't think it would help for the programs we write here at MC, but 
who knows the only way to really find out would be to implement it.
--------------------------------------------------------------------------
mercury-developers mailing list
Post messages to:       mercury-developers at cs.mu.oz.au
Administrative Queries: owner-mercury-developers at cs.mu.oz.au
Subscriptions:          mercury-developers-request at cs.mu.oz.au
--------------------------------------------------------------------------



More information about the developers mailing list