(j3.2006) IEEE and the GPU world

[Bill Long]

John Reid wrote:
> Bill Long wrote:
>> The IEEE feature in F03 is becoming the topic of discussion with the 
>> advent of the Chinese GPU system hitting #2 on the Top 500 list, and 
>> also users getting access to the GPU's in their laptops via schemes like 
>> OpenCL.
>>
>> While GPU's support the hardware bit patterns for IEEE floating point 
>> format (more or less a requirement for them to be useful at all for 
>> floating point in a shared data environment),  they do not support 
>> things like exception flags or interrupts (halting), mainly for 
>> performance reasons.
>>
>> The question is what values should users expect from routines like 
>> IEEE_SUPPORT_HALTING and IEEE_SUPPORT_FLAG?    The standard is worded as 
>> if there is a single "processor".  But the common configuration will be, 
>> at least at the beginning, of a combination of a "normal" processor 
>> (x86_64, for example) for which these inquiry functions would return 
>> true, and a GPU for which false is the right answer.   Does the presence 
>> of the GPU code pollute the entire program (functions return false no 
>> matter where called in the program), or do they return true if called in 
>> part of the code that is compiled into instructions for the normal 
>> processor, and false if called from  the parts of the code compiled for 
>> the GPU?   Note that the programmer would not necessarily know which 
>> parts of the program end up executing on which hardware type.  Insights 
>> from the designers of this feature would be particularly interesting.
> 
> I think the standard is pretty clear. 14.1:p2 says
> 
> "If IEEE_EXCEPTIONS or IEEE_ARITHMETIC is accessible in a scoping unit, the 
> exceptions IEEE_OVERFLOW and IEEE_DIVIDE_BY_ZERO are supported in the scoping 
> unit for all kinds of real and complex IEEE fl oating-point data. Which other 
> exceptions are supported can be determined by the inquiry function 
> IEEE_SUPPORT_FLAG (14.11.27); whether control of halting is supported can be 
> determined by the inquiry function IEEE_SUPPORT_HALTING. ..."
> 

Thanks for the quick reply. That gives enough to specify the 
implementation rules.  If the user requests (perhaps by default) that a 
program unit is compiled with the optimization level set to generate any 
subset of its code for the companion GPU,  and these modules are 
accessible, then either

1) A warning is issued saying that the optimization was disabled because 
these intrinsic modules are accessible, or

2) An error is issued saying that these intrinsic modules must not be 
accessible for a procedure that is partially executed on a GPU.

I suspect that the end result might be that references to these modules 
will be routinely removed from, or never inserted into, the 
computational sections of programs to avoid the problem.  Modules that 
are used by the GPU-targeted codes would also have to be "clean".  Maybe 
not the goal of the original IEEE feature.

Cheers,
Bill


> and 14.1:p3 says
> 
> "If a scoping unit does not access IEEE_FEATURES, IEEE_EXCEPTIONS, or 
> IEEE_ARITHMETIC, the level of support is processor dependent, and need not 
> include support for any exceptions. If a  flag is signaling on entry to
> such a scoping unit, the processor ensures that it is signaling on exit. If a 
> flag is quiet on entry to such a scoping unit, whether it is signaling on exit 
> is processor dependent."
> 
> Cheers,
> 
> John.
> 
> _______________________________________________
> J3 mailing list
> 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