(j3.2006) F03/0084, was Re: Interp letter ballot #25

[Bill Long]

On 5/11/12 3:15 PM, Keith Bierman wrote:
>
> On Fri, May 11, 2012 at 2:03 PM, Van Snyder <Van.Snyder at jpl.nasa.gov
> <mailto:Van.Snyder at jpl.nasa.gov>> wrote:
>
>     ....troversy concerning this issue at
>     that time. There are ways processors can reduce this problem. In any
>     case, the fraction of deployed processors that are members of this class
>     has been dwindling for decades.
>

For processors that use a "state" register to determine rounding modes 
and other ieee characteristics, changing modes is painfully slow. 
Surprisingly, there is limited demand for a "slow" option.  If the mode 
is incorporated into each hardware floating point  instruction 
separately, then the performance penalty is much less.  But, as Van 
points out, there are very few of those shipped.

>
> Really? Aren't most of the GPU devices precisely hobbled this way? They
> are gaining a certain amount of traction for computational work.
>

When you get to GPU-land, you end up returning  .false. for many of the 
"ieee_support..." inquiries in Clause 14.  Particularly, 
IEEE_SUPPORT_HALTING which is the one most people are interested in. 
(Among the small fraction of users who use any feature in Clause 14.)


> I don't have a strong opinion about the rest of the argument ... not
> that I'm working on it; but it seems to me that the appropriate place
> for Interval work would be in a new language (related to Fortran the
> same way that Java is related to C++) ... inspired, but not directly
> descended.

Coming up with a new language is a lot of work, and getting people to 
use it has a poor track record.   Have any of the "new" languages 
included support?  Not that I know of.  I'm not seeing the demand (= 
vendor motivation).

>
> There's just too much that ought to be different to make it ideal, and
> halfway measures aren't really useful in the long run.
>

Agreed.  For Fortran, I think a main problem is that the implementation 
cost is out of proportion to the expected usage.  We get stung by 
"simple" features that turn out to be pigs to implement.  In this case 
we know in advance that it is a pig.

Cheers,
Bill

>
>
>
> _______________________________________________
> 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