(j3.2006) IEEE and the GPU world

[Dick Hendrickson]

On Wed, Jun 23, 2010 at 12:52 PM, Bill Long <longb at cray.com> wrote:

>
>
> 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.
>
> Isn't there a third option to issue a warning saying that using both IEEE
and GPU together is non-standard conforming and that the compiler will
compile on a best efforts basis?  That's a short term fix.

The various IEEE_SET_* routines contemplate that many of the IEEE things
will work differently in different parts of a routine.

Dick Hendrickson

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
>
>
> _______________________________________________
> J3 mailing list
> J3 at j3-fortran.org
> http://j3-fortran.org/mailman/listinfo/j3
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://j3-fortran.org/pipermail/j3/attachments/20100623/35a00e2a/attachment.htm>