
Boost : 
Subject: Re: [boost] Looking for some "real world" extended precision integer arithmetic tests
From: John Maddock (boost.regex_at_[hidden])
Date: 20120125 05:22:16
> I was following development process of your library and was just waiting
> this moment. I'll test your fixed_int code and compare it to my own
> implementation.
> FYI gmp library performance was 4 times slower comparing to my fixed_int
> implementation.
>
> I was also wondering if it's possible to provide generalized interface for
> the Boost licensed big_number and specifying underlying data storage using
> template parameter (boost::array for fixed integers or vector for not
> fixed
> integers). Most of the operations implementations (addition,
> multiplication
> and all the others) should remain the same. You may want to have a look at
> this code:
> http://svn.boost.org/svn/boost/sandbox/SOC/2007/bigint/boost/bigint/bigint_storage_fixed.hpp
> http://svn.boost.org/svn/boost/sandbox/SOC/2007/bigint/boost/bigint/bigint_storage_vector.hpp
> http://svn.boost.org/svn/boost/sandbox/SOC/2007/bigint/boost/bigint/bigint_default.hpp
> I would suggest that this way you should get not fixed int implementation
> performing almost the same as fixed_int, and as a plus you would not
> need tommath_int
> anymore.
It's an interesting idea  but at present I'm thinking that fixed_int is
specialized enough to warrant it's own implementation  it's 2's complement
where as almost all (all?) arbitrary precision types are signedmagnitude,
there are also some operations that can be significantly streamlined for
fixed precision 2's complement modulo arithmetic types (for example long
multiplication doesn't need to calculate all the places in the result) which
is the reason many operations can outperform GMP *even excluding memory
allocations*. There's also the interesting effect, that since the array
bounds are known at compile time, the compiler can unroll and / or vectorize
the loops  and it can probably do that almost as well as hand written
assembly.
That said, since all the algorithms are nonmember functions anyway, there
may well end up being some possibility of code sharing further down the
road...
Cheers, John.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk