[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