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-24 12:50:59

> >I'm continuing to add to the multiprecision arithmetic library in the
>>sandbox (under "big_number"), and I've just added a Boost licensed
>>fixed-precision integer type which on Win32 at least looks to be very
>>competitive with GMP for reasonable numbers of bits (up to about 1024), 
>>see
>>http://svn.boost.org/svn/boost/sandbox/big_number/libs/multiprecision/doc/html/boost_multiprecision/perf/integer_performance.html
>
> Wow, those are some big numbers you are putting up.  You must be stoked.
>
>>However, as we all know there are lies damn lies and performance stats ;-)
>>Plus the test results I have above ignore the effect of memory allocations
>>(needed by libtommath and GMP, but not the fixed_int code - which in 
>>theory
>>should make it faster still).  So I'd be really interested to put the type
>>through it's paces with some real world code that really thrashes an
>>extended precision integer type.  Any suggestions?  Anything in Boost?
>
> In my experience memory allocations dominate gmp performance for modest 
> sized big numbers.
>
> My library uses infinite precision rational data type.  I would love to 
> see your library interoperate with boost rational.  However, because I use 
> lazy exact you would not be able to observe much effect of using a 
> different numerical data type with my library.

The number types I have can all be plugged straight into Boost.Rational. 
However, performance compared to say mpq_t is truly terrible.  Not sure if 
it's Boost.Rational or Boost's gcd that's the bottleneck, though I suspect 
both could be improved.

> The voronoi diagram feature being implemented in my library by Andrii as 
> part of GSOC2010 implements its own extended precision arithmetic (float 
> and int) and has performance that is more heavily dependent on the 
> numerical data type because for line segements, at least, it is impossible 
> to avoid extended precision in the common case.  You should work with 
> Andrii to both make sure your library works well for his needs and collect 
> performance results with his tests.

Sure, where do I find him?

Thanks, John.