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