Re: [boost] [review] Multiprecision review (June 8th - 17th, 2012)

Subject: Re: [boost] [review] Multiprecision review (June 8th - 17th, 2012)
From: Jeff Flinn (Jeffrey.Flinn_at_[hidden])
Date: 2012-06-25 11:59:09

On 6/25/2012 11:15 AM, John Maddock wrote:
>> FYI, Several years ago, implementing a Runge Kutta integrator and
>> solver, we found that removing the explicit divide by zero check and
>> relying on the hardware signal to propagate as an exception gave a 40
>> - 60% performance improvement. Though, I'm not sure how that
>> translates to today's hardware/compilers and data types used.
>
> Interesting - thanks!
>
> I take it this was with native int's and not extended precision ones? I

Yes, these were purely native types.

> ask because typical long division algorithms are rather expensive - as
> in O(N^2) with a biggish constant as well.
>
> That said, values that are small enough to fit in an int, but are
> actually in an extended type "just in case" are an important use case,
> and as supporting that case efficiently still needs more work, I guess I
> shouldn't hamper that effort too much.... so I guess it's back to a
> compile time switch....

In our case the incidence of divide by zero was a very small percentage 
of the total iterations. The real cost of the if(...) was during all of 
the non-zero iterations. As you say it could be negligible compared to 
the other work being done.

Jeff