Re: convert mpf t to double with rounding-modes defined by ieee754
usenett at gmx.de
Mon Aug 1 12:16:29 CEST 2005
> > 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
GMX DSL = Maximale Leistung zum minimalen Preis!
2000 MB nur 2,99, Flatrate ab 4,99 Euro/Monat: http://www.gmx.net/de/go/dsl
More information about the gmp-discuss