[mercury-users] abstract types.

Ralph Becket rbeck at microsoft.com
Mon Jan 17 22:55:02 AEDT 2000


This is exactly the optimisation I employed for
my performance comparison paper (still in draft
form); it made for a dramatic speed-up (x2).
Replacing the use of 234-trees with hash tables
made for another x3 speed-up.  Other speed-ups
included using stores to keep track of singly
threaded state vectors (x2) and changing from
closed addressing in the hash table (i.e. with
lists of buckets) to open addressing (i.e. two
hash functions) (again, x2).

The store trick should be unnecessary once
structure reuse is available; the library really
needs a hash table implementation or two.

Cheers,

Ralph

> From: Thomas Conway [mailto:conway at cs.mu.OZ.AU]
>
> How should I implement an abstract form of lr1item? I'd like 
> the interface
> to be the same:
> 	:- type lr1item.	% abstract
> or
> 	:- type lr1item == int.
> 
> along with:
> 	:- func lr1item(prodNum, dot, symbol).
> 	:- mode (lr1item(in, in, in) = out) is det.
> 	:- mode (lr1item(out, out, out) = in) is det.
--------------------------------------------------------------------------
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