[PPL-devel] [Fwd: Re: mpz_t C++ wrapper]

[Roberto Bagnara]

-------- Original Message --------
Subject: Re: mpz_t C++ wrapper
Date: Tue, 6 May 2008 13:32:37 +0200
From: Heiko Wundram <modelnine at modelnine.org>
To: Roberto Bagnara <bagnara at cs.unipr.it>
References: <200804302026.40931.modelnine at modelnine.org> <4819B955.9050809 at cs.unipr.it>

Am Donnerstag, 1. Mai 2008 14:36:37 schrieben Sie:
> Heiko Wundram wrote:
> > but if there's any code base
> > out there using mpz_class extensively (or someone knows of one they can
> > point me at; Google isn't especially helpful here), I'd happily give any
> > interested party access to the source so that they can test how/if my
> > reimplementation fares better for them.
>
> The Parma Polyhedra Library uses mpz_class extensively.  However, care has
> been taken to minimize the creation of temporaries.  Still, I think it
> would constitute a good benchmark for your code.

Over the weekend, I've implemented a similar mpq_t wrapper, which was still
missing to benchmark the PPL, and that's checked into the URL I posted before
now. The code that I checked in there isn't 100% compatible with the
traditional mpz_class and mpq_class types, but comes close.

The changes to biginteger.hh to be able to compile PPL are straightforward
(and only concern function naming), and in case you're interested, I've
attached the unified diff against ppl-0.9.tar.bz2 which removes one function
(cmp(mpz_t,mpz_t)) from GMP_Integer.inlines.hh, which is implemented by the
wrapper directly, and makes an explicit cast from an expression involving an
mpq_t to mpz_t (which is not done implicitly by the biginteger
implementation), and also includes the adapted biginteger.hh (which puts all
code into namespace Parma_Polyhedra_Library, basically). Other than that, the
code compiled directly, and also produces the same results (as far as I could
let the examples run because of my limited processing power), except for one
example, which produces a different result only because the
mpq_class(mpz_class,mpz_class) constructor canonicalizes its value in my
implementation, whereas the mpq_class(mpz_class,mpz_class) constructor from
gmp++ doesn't (which is basically a bug in ppl_lcdd AFAICT, because an
mpq_class instance created from user data has to be normalized for most mpq_*
methods on it to work properly).

I've only done simplistic benchmarks so far (using demos/ppl_lcdd/ppl_lcdd),
but possibly you're interested to know that I'm seeing at least a slightly
better runtime over the gmp++ implementation of the two types. It's not a
dramatic decrease in runtime, but for "reg600-5_m.ext", the gmp++
implementation averages at around 7.070s user time on my Turion MT-32 system,
whereas the biginteger implementation averages at around 7.005s user time (in
both cases, the system ran at 1800Mhz and of course ppl_lcdd used the same
libgmp). That's around 1% better.

Anyway, thanks for your interest and the hint at PPL (which got me to actually
implement mpq_t, which I don't need), and I'll get back to what I actually
wanted to achieve with the wrapper now, which only concerns cryptography. ;-)

-- 
Heiko Wundram


-- 
Prof. Roberto Bagnara
Computer Science Group
Department of Mathematics, University of Parma, Italy
http://www.cs.unipr.it/~bagnara/
mailto:bagnara at cs.unipr.it
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ppl.diff
Type: text/x-diff
Size: 130009 bytes
Desc: not available
URL: <http://www.cs.unipr.it/pipermail/ppl-devel/attachments/20080506/f9db5bd5/attachment.diff>