(j3.2006) Liaison to IFIP WG 2.5
William B. Clodius
wclodius
Thu Aug 23 00:51:34 EDT 2007
On Aug 22, 2007, at 2:35 PM, Andy Vaught wrote:
> On Wed, 22 Aug 2007, Van Snyder wrote:
>
>> On Wed, 2007-08-22 at 19:59 +0100, Lawrie Schonfelder wrote:
>>> I thought intervals were about accuracy critical not performance
>>> critical!
>>
>> In many applications, if performance costs 100 times as much, accuracy
>> will be reluctantly sacrificed. Ultimately, the scientists will blame
>> the software engineer for the situation.
>>
>> And interval arithmetic isn't just about accuracy. Some algorithms
>> are
>> not guaranteed to work, or are impossible altogether, in point
>> arithmetic, while they are guaranteed to work in interval arithmetic.
>> The poster child for this is global minimization.
>
> While you're arguing about the goodness of interval arithmetic, I
> still
> don't see the reason why it should be part of standard fortran. People
> have written interval arithmetic packages using derived types and
> operator
> overloading. As far as I can tell, the code ultimately generated
> would be
> pretty much the same either way, particularly if the compiler is clever
> with inlining.
> <snip>
No, for several reasons, some intrinsic to the language, some the
characteristics of the language's implementations. The language is
awkward for specifying the desired semantics as it is looser in
specifying the semantics of floating point operations than interval
arithmetic desires. If the intervals are to be minimized temporaries
need to be maintained at as high a precision as possible as long as
possible. Maintaining this precision is further complicated by
Fortran's neglect of result type in generic resolutions. The effect of
parentheses etc., on the distributive properties of Fortran's floating
point math, also makes it awkward to write optimal interval arithmetic
expressions.
As to the implementations, the optimal tradeoff between branches and
explicit arithmetic operations will be processor specific. The larger
number of operations involving the same values, in interval arithmetic
compared with normal arithmetic, also increases register pressure. The
raw source code will have explicit changes in the rounding modes of the
processor. These changes in mode correspond to changes in state that
normally inhibit optimization, i.e., drain pipelines. In principle the
order of register loads can be changed in coordination with the
rounding modes and maintain the desired semantics, but I suspect the
fraction of code that dynamically changes rounding mode is so small
that compiler writers don't implement these optimizations. Even if they
do implement these optimizations, it is likely to be in a general form
that approximately solves the combined register/rounding mode pressure
by a metric different from what the interval arithmetic people consider
ideal. It will not (significantly) consider maintaining precision, and
it will not recognize idioms specific to interval arithmetic that allow
higher optimization.
--
William Clodius
More information about the J3
mailing list