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

Kral Stefan skral at mips.complang.tuwien.ac.at
Tue Sep 20 01:40:39 AEST 2005


Dear Zoltan, 

Thank you for taking the time to help me with my little
Mercury-GMP bindings project!

On Mon, 19 Sep 2005, Zoltan Somogyi wrote:
> On 14-Sep-2005, Kral Stefan <skral at mips.complang.tuwien.ac.at> wrote:
> > To allow the creation of unique copies, the GMP binding(s) will
> > offer dedicated functions/predicates, like the following.
> > 	:- pred gmpint_copy(gmpint, gmpint).
> > 	:- mode gmpint_copy(in,     uo) is det.
> > 	:- mode gmpint_copy(di,     uo) is det.
> 
> What is the purpose behind allowing users to create unique copies? 
> What can they do with them that they cannot do with nonunique copies?
I had no particular purpose in mind.

But, now that you ask;-) Forcing the creation of unique copies can
be helpful for micro-benchmarks, evaluating the performance of the
library. The GMP library is smarter than we (thought), eg. it 
detects that X*X can be done by using a specialized, faster 
algorithm for calculating squares. To turn that optimization off, 
we can force the creation of a unique copy.

Generally, I concur with you. In a real application setting, 
I do not see a use for it, either...

> > I noticed that using that assertion caused the compiler to omit some
> > boxing/unboxing statements (which -- I believe -- are optimized away
> > anyway by the C compiler, as it knows about the sizes of MR_Word and
> > GMPInt *).
> 
> The last time I checked, which wasn't recently, the C compiler didn't 
> optimize away the boxing and unboxing code, which calls memcpy.
I did a few little performance tests with gmpint, and had a glimpse
at the C code produced by the Mercury compiler.

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.
That would explain why I noticed no performance difference at all
in my micro-benchmark.

> > Our current implementation does not alter memory of values that are alive.
> > However, we reuse memory wherever possible.
> > 
> > I am not sure if this suffices to quality the type as stable.
> 
> The design intent behind the "stable" annotation was to allow tabling
> (memoization etc), which requires that the memory pointed to stay unchanged
> until execution ends, so no, it doesn't qualify. However, it is sufficient
> to make it safe for copy operations to ignore the value, *provided* that
> you don't reuse the memory until all copies referring to it are dead.
> It looks like another annotation that promises just that may be useful.
> In the meantime, you may use the stable annotation as a workaround
> if you can ensure that you won't table values of the type.
I think my last statement in this regard was misleading.

The library reuses memory wherever possible, but only in
a clean way, using unique modes. Apart from that, everything
is clear and simple, using the conservative GC interface.

In retrospect, I think that this qualifies the type as stable.

Incidentially, I tried memoization in a little fibonacci demo, 
calculating fibonacci by using the following definition
	F[0]    = 0
	F[1]    = 1
	F[2]    = 1
	F[2k]   = F[2k+1] - F[2k-1]	if 2k > 2
	F[2k-1] = F[k]^2 + F[k-1]^2	if 2k-1 > 2
in a straight-forward manner.

Everything seems to work out well! All results so far have been
correct, fibonacci is a roughly a factor of two slower than a 
(in my sense) brutally optimized C routine, that consists of 
more than 400 lines of code.

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.
We still need to prepare some more demos and improve the documentation.

Also, we need to do some pseudo benchmarks, especially to ease
comparison of performance of code run in 32-bit or 64-bit mode.
(I have been following some of the discussion going on about "Saturn"
in one of your mailing lists...)

Best Regards,
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
--------------------------------------------------------------------------



More information about the users mailing list