[mercury-users] User-defined Extension of builtin__copy?

[Kral Stefan]

On Wed, 21 Sep 2005, Zoltan Somogyi wrote:
> You are welcome.
Thanks!

> How does that help? Does GMP decide whether two operands are the same
> by comparing their addresses?
No. Of course, equality and comparison are defined properly.

But the routine for X*Y quickly checks if the pointers to X and Y
are equal, and calls a squaring routine in that case (which is
usually 50% faster)...

> > Apparently, the boxing/unboxing checks looks something like
> > 	if (sizeof(GMPInt *) <= sizeof(MR_Word)) { ... }
> > 
> > Any reasonable C compilers should be able to optimize that check away.
> 
> Yes, of course. However, in one arm of the switch, there is a call to
> memcpy (buried under several layers of macros). If the size is such
> that you get the arm without the memcpy, there should be no performance
> impact, as you found. There should also be no impact if the C compiler
> specializes the memcpy with the constant size argument, but as of about
> three/four years ago, it didn't do that.
Ok.. So it would be okay if I specified (promised)
that the pointer can pass in a MR_Word?

> > In retrospect, I think that this qualifies the type as stable.
> You aren't allowed to table predicates that have unique arguments
> (the table's references to the arguments would destroy their uniqueness).
I found out about that restriction, and of course, it is 
perfectly reasonable. In situations like fib, the tabling
gives much more performance than the immediate reuse could, anyway.

The fibonacci demo is built will show the differences,
comparing a plethora of variants. I will integrate that
into the binding library.

> If I understand you correctly, you won't ever reuse the memory of
> a nonunique gmpint, so I agree, gmpints can be said to be stable.
Good.

> > I am confident that gmpint is getting more and more mature.
> > (We are working on gmpfloat and gmprational libraries, too.)
> > Our integer GMP-bindings will be ready for release in just about 2 weeks.
> 
> That's nice to hear.
I think Mercury is much more suitable than C for coding larger
entities of code, that actually work. 

I think I have found in the GMP implementation of fibonacci (which
is written in C). Its Mercury counterpart run clean and smoothly.
(I will have to check that out in detail and contact the
GMP developers in this respect.)

Gotta go now! 2nite Steve Vai is coming to town;)

Cheers,
Stefan.

--
Stefan Kral			http://www.complang.tuwien.ac.at/skral

--------------------------------------------------------------------------
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
--------------------------------------------------------------------------