(j3.2006) Interval arithmetic

[Bill Long]

Van Snyder wrote:
>
>> All us implementors know we're not supposed to move computations
>> across a statement that changes the rounding mode.
>>     
>
> If you actually look into an interval arithmetic package, you'll see
> that they store their results into volatile variables.  This is
> correspondence from Christian Keil c.keil at tu-harburg.de on the P1788
> mailing list:
>   

Except in the irrelevant x87 case, this does not make sense to me.  
Rounding occurs as part of a computation operation (in the add, 
multiply, or divide units, for example), or with an explicit format 
conversion.  Rounding does not occur as part of a memory transfer.  I 
don't see how sending a block of bits from a register to memory and then 
loading the exact same bits back into a register can affect rounding.


> ! That's exactly what interval packages (PROFIL for example) do right now
> ! to enforce (among others) rounding of intermediate results... Hopefully
> ! the standard will allow us sometime to get rid of these.
>
> So, no, although NAG probably does know not to move intermediate results
> across statements that change the rounding mode, there are evidently
> plenty who don't, and correcting this "quality of implementation" defect
> is usually quite low on their priority lists.  Apparently, unless
> NASTRAN or SPEC say it's a problem, the standard(s) needs to say it's
> prohibited.
>
>   
The fact that a compiler might implement the standard incorrectly is not 
automatic grounds for changing the standard.


Van also comments on efficiency.  Changing the rounding mode is, 
generally, a very expensive thing to do.  You have to complete all the 
currently in-flight floating point instructions before changing the mode 
setting.  This kills the pipelining of instructions and results in a 
pretty big performance hit.   I don't see how this problem is materially 
helped by having the compiler know more about the interval type.  If an 
intrinsic interval type will require frequent rounding mode changes, 
then the performance will be poor no matter what.   But, then, it is 
hard to imagine any real applications being coded with intervals, given 
the intrinsic performance penalty of at least 2X.  Do the academics 
actually interested in this capability really care that much about 
performance?

Cheers,
Bill




-- 
Bill Long                                   longb at cray.com
Fortran Technical Support    &              voice: 651-605-9024
Bioinformatics Software Development         fax:   651-605-9142
Cray Inc., 1340 Mendota Heights Rd., Mendota Heights, MN, 55120