(j3.2006) IEEE and the GPU world

[Keith Bierman]

On Sun, Aug 29, 2010 at 6:44 AM, Bill Long <longb at cray.com> wrote:

>
>
> John Reid wrote:
>
>
>> Do we want the possibility of a block and its host being implemented on
>> different hardware? As we have it now, this is a possibility. I thought this
>> was a mistake. What do others think?
>>
>>
> As a practical matter, large loop nests are appropriate for execution on a
> GPU.  A given subprogram would be executed partly on the main CPU and partly
> on the GPU.   So the GPU section of the code will almost always be within a
> surrounding host of non-GPU code.   The BLOCK just provides a means of
> narrowing the reach of USE statements in the host.
>
> For what little it's probably worth, this was part of what some of us had
in mind when we started down the IEEE module path. Back in the 1980s, when I
worked at Cydrome, we had six 68020s (I could be misremembering the next to
last digit) and a LIW numeric engine. While it was totally transparent to
the user (ala the 6600) program execution was split between the very
different processors. Fortunately, the architects had made the numeric
engine fully IEEE compliant for all of the basic instructions (Kahan had
claimed we had the very first fully compliant pure hw divide/sqrt unit) but
in the follow on system (never built) there was discussion about altering
that so that the numeric engine wouldn't have that pesky IEEE arithmetic to
obsess about. Unlike the old CDC (which I have no proof, but think inspired
the overall architecture) where all of the FP execution was on the numeric
engine(s), on the Cydra5 much was done on the "peripheral processors" (not
what we called them).

Also the original SPARC systems were conceived of with a 6881 as well as the
weitek chips to augment the original Fujitsu gate-array chip (not what
actually shipped, so don't go to wikipedia!) so it seemed likely to be that
the split of IEEE/non-IEEE processing would be a likely eventual outcome
(and the current discussion on another list about OpenCL is driving that
home).


However, I am unsurprised that the idea didn't make it clearly into the
Standard. Sorry about that.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://j3-fortran.org/pipermail/j3/attachments/20100829/278209c0/attachment-0001.htm>