Re: [boost] Looking for some "real world" extended precision integer arithmetic tests

Subject: Re: [boost] Looking for some "real world" extended precision integer arithmetic tests
From: John Maddock (boost.regex_at_[hidden])
Date: 2012-01-25 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 signed-magnitude, 
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 non-member functions anyway, there 
may well end up being some possibility of code sharing further down the 
road...

Cheers, John.