convert mpf t to double with rounding-modes defined by ieee754
Patrick Pelissier
Patrick.Pelissier at loria.fr
Mon Aug 1 15:07:36 CEST 2005
On Mon, Aug 01, 2005 at 12:16:29 +0200, usenett at gmx.de wrote:
> > > I don't want to say that MPFR is inefficient, I'm far away from =20
> > > this view.
> > > But for my situation (simulating a long accumulator) I prefer GMP, =20
> > > cause
> > > MPFR has a bigger functionality than I need and that makes it slow =20
> > > for my
> > > purpose.
> >
> > I don't see how bigger functionality and speed are related. Do you =20
> > have actual numbers to back up your statement, or is this just an =20
> > instance of the old `C++ is slow' mentality?
> >
> > > The only advantage is the closing rouned double conversion.
> > > Of course later on a comparison between my implementation and MPFR =20
> > > would be
> > > interesting.
> >
> > I find it very hard to believe that you could do better than MPFR. =20
> > It's not like the MPFR authors are some random web/VB code monkeys =20
> > releasing a weekend project on Sourceforge.
>
> I tested my computation throughout with GMP and as well with MPFR. Working
> with a large accumulator (in my case a variable with precision of 4288
> bits), in which perhaps only some few limbs are used, the mpfr-version is
> about a factor of 4-5 slower. That has neither anything to do, that the mpfr
> authors are 'some random web/VB code monkeys', nor that 'C++ is slow'. The
> mpfr-library just doesn't fit to my problem. The way some things are
> realized in gmp seem to be more profitable to me (just in my case, not
> generally).
Which functions did you use?
What do you mean by "MPFR doesn't fit my problem"?
In my own benchs, MPFR is as fast as MPF. It evens beat MPF in some.
--
Patrick Pelissier
More information about the gmp-discuss
mailing list