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: Simonson, Lucanus J (lucanus.j.simonson_at_[hidden])
Date: 2012-01-24 12:02:06

>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 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.

Regards,
Luke