(j3.2006) IEEE and the GPU world

[Bill Long]

Keith Bierman wrote:
> Should the Standard really prescribe that deeply?
> 

The wording in the standard is a bit unusual.  It says that "If [modules 
accessible] then [exceptions] ARE supported".  This is written as a 
statement of fact, and as a requirement on the processor. From that I 
conclude that the processor is obligated to not compile the program if 
the "fact" is not true.  If the wording had been  "[modules] shall be 
accessible ONLY IF [exceptions] are supported", then I would read that 
as a requirement on the programmer. Programmer mistakes can be handled 
as a non-conforming program, and the processor is allowed to do more or 
less anything.  Including any of the accommodations suggested by Dick or 
Keith.



> On  a GPU that observes only the bit patterns but nothing else, I'd hope 
> that whether the IEEE stuff "worked" was a compiler option .. because 
> clearly anyone trying to do careful numerical reasoning is going to want 
> "no" and people who are more relaxed might want a different answer so 
> they could keep their source code "the same".
> 

Such compiler switches are already available to control levels of 
optimizations that affect numerical operations (such as changing a 
divide to a multiply by a reciprocal).  Typically they have not affected 
the behavior of the procedures in the IEEE modules, but that could be 
considered.


> Future GPUs might have better support, at least for some features, and 
> then it's more like what Dick suggests ;>
> 

It is reasonable to speculate that future GPU's will have better 
support.  Or that the "normal" chips will take on enough of the GPU 
characteristics (massive internal parallelism, in particular) that the 
GPU will become irrelevant for non-graphics programming.  Either way, 
the nature of the problem changes over time.

Cheers,
Bill



> The current GPU situation is vaguely akin to the early array processors 
> (FPS, et al) we didn't craft special definitions for them, the market 
> moved on, and better integrated solutions won the day (and made for an 
> easier model for the Standard ;>).
> 
> History doesn't always repeat, but it is often the way to bet ;>
> 
> 
> Keith Bierman
> khbkhb at gmail.com <mailto:khbkhb at gmail.com>
> kbiermank AIM
> 303 997 2749
> 
> 
>     _______________________________________________
>     J3 mailing list
>     J3 at j3-fortran.org <mailto:J3 at j3-fortran.org>
>     http://j3-fortran.org/mailman/listinfo/j3
> 
> 

-- 
Bill Long                                           longb at cray.com
Fortran Technical Support    &                 voice: 651-605-9024
Bioinformatics Software Development            fax:   651-605-9142
Cray Inc./Cray Plaza, Suite 210/380 Jackson St./St. Paul, MN 55101