From owner-sc22wg5+sc22wg5-dom8=www.open-std.org@open-std.org Fri Jan 18 08:40:36 2013 Return-Path: X-Original-To: sc22wg5-dom8 Delivered-To: sc22wg5-dom8@www.open-std.org Received: by www.open-std.org (Postfix, from userid 521) id 9C600356CAD; Fri, 18 Jan 2013 08:40:36 +0100 (CET) Delivered-To: sc22wg5@open-std.org Received: from mail-ia0-f180.google.com (mail-ia0-f180.google.com [209.85.210.180]) by www.open-std.org (Postfix) with ESMTP id D2A1C356CA9 for ; Fri, 18 Jan 2013 08:40:35 +0100 (CET) Received: by mail-ia0-f180.google.com with SMTP id f27so1074422iae.25 for ; Thu, 17 Jan 2013 21:42:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=rFlZp2c/GA/WaysT9u7NiIl+n90MGBpQHrbFld0fCog=; b=x82UMTzb9+0Byhfbbt4CDPDoEtUrUlVK64ghBUkynlJFkbSaIgJDhIps8+pjNvhFWf YBJ9RI5VYN3DSuIo7ARKW3PPvfYNsBSd5xPfjns7oMrcpDXg7/eHrhitJU7Wb54yYMPn AwgxU012EC/4DRgaySlkIHOSIfxWzPYpgBxptVNcSXMz4GD7DTW2lza9Glv3rs4ffm9X JI2bh0hqlfXCUQ8sgdeIlFHuG468p8UMDZCKroNxkfthr5AmhvZCy+0or8WpH9EPizT/ 1g4L+SPe7wOkDLBx4CY/AClzj9vBf3d90TGgUQnV42f2NiRk//wGcuxM7BrbAj8s3ftD bn5w== X-Received: by 10.50.7.204 with SMTP id l12mr1080654iga.103.1358487722867; Thu, 17 Jan 2013 21:42:02 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.9.38 with HTTP; Thu, 17 Jan 2013 21:41:22 -0800 (PST) In-Reply-To: <20130118070037.7E831356CA9@www.open-std.org> References: <20130108205438.50F4E356B56@www.open-std.org> <20130113210632.B1C67356BEA@www.open-std.org> <20130116050422.92E30356BE0@www.open-std.org> <20130116191114.A6A75356A2B@www.open-std.org> <20130118070037.7E831356CA9@www.open-std.org> From: Keith Bierman Date: Thu, 17 Jan 2013 22:41:22 -0700 Message-ID: Subject: Re: (j3.2006) (SC22WG5.4909) [ukfortran] Comment on a comment on the WG5 letterballot on N1947 To: fortran standards email list for J3 Cc: WG5 Content-Type: multipart/alternative; boundary=f46d04446b0b273d5b04d38992a2 Sender: owner-sc22wg5@open-std.org Precedence: bulk --f46d04446b0b273d5b04d38992a2 Content-Type: text/plain; charset=ISO-8859-1 Malcolm, I was not referring to YOU when I suggested that some do not appreciate the costs. Nor did I intend to imply that John's proposal was voted down because of integer exceptions. Yes, if we count by sheer numbers, hardware which can do this efficiently have become numerous. However, somewhat less so at the "high end" where a lot of Fortran still rules the roost. But I know you are quite in touch with a wide spectrum of users on interesting platforms. The other class of cost, of course, is scarce committee time. I shall not take up any more of it with this topic. Those of you currently doing the work can and should choose how to spend your committee time. Best wishes, khb Keith Bierman khbkhb@gmail.com kbiermank AIM 303 997 2749 On Thu, Jan 17, 2013 at 10:01 PM, Malcolm Cohen wrote: > Keith Bierman wrote: > >OpenVMS, as far as I know, has only run on processors which physical > support > >for overflow detection (Alpha, VAX). So this is not a very useful proof > point > >for the significant number of processors that do not have such hardware > >support. > > The vast majority of processors, including the x86 family, have such > hardware > support. > > >> 2. Detection of integer overflow conditions was part of John > Reid's > >> ENABLE block > >>proposal in 1994. > > > >John was proposing a language feature; > > he didn't have the burden of actually implementing it, > > so again this example > >proves nothing germane to Bill's objections. > > John's ENABLE block was not shot down by people raising objections to > integer > overflow detection. > > >Look at current GPU architecture manuals and hardware specifications for > >examples of compute engines for which such handling could prove quite > costly > >(indeed, making moving computation off the CPU possibly pointless). GPUs > are > >similar (in many ways) to the old FPS style array processors and Cray > style > >vector machines (just not nearly as polished or easy to program). > > > >I'm not saying that these aren't useful or interesting language features. > But > >those without any "skin the game" w.r.t. >implementing either the > hardware or > >software should not blithely ignore the costs proposed. > > (1) No-one is blithely ignoring anything. > (2) I do in fact know what it costs in hardware and software; in hardware > the > costs are not zero but they are miniscule compared to many other cute > features > that are being implemented. > (3) I have in fact implemented it in software without using the hardware > support. > > Or the snarkier but more amusing: > > "Losing a rocket on the launch pad: a few billion dollars. > Being able to brag about your GPU: priceless." > > Cheers, > -- > ................................Malcolm Cohen, Nihon NAG, Tokyo. > > _______________________________________________ > J3 mailing list > J3@mailman.j3-fortran.org > http://mailman.j3-fortran.org/mailman/listinfo/j3 > --f46d04446b0b273d5b04d38992a2 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Malco= lm, I was not referring to YOU when I suggested that some do not appreciate= the costs.

Nor did I intend to imply that John's proposal was voted down = because of integer exceptions.

Yes, if we count by sheer numbers, hardware which can do this=A0ef= ficiently=A0have become numerous. However, somewhat less so at the "hi= gh end" where a lot of Fortran still rules the roost. But I know you a= re quite in touch with a wide spectrum of users on interesting platforms.

=
The= other class of cost, of course, is scarce committee time. I shall not take= up any more of it with this topic. Those of you currently doing the work c= an and should choose how to spend your committee time.

Best wishes,
khb

Keith Bierman
khbkhb@gmail.com
kbiermank AIM
= 303 997 2749


On Thu, Jan 17, 2013 at 10:01 PM, Malcol= m Cohen <malcolm@nag-j.co.jp> wrote:
Keith Bierman wrote:
>OpenVMS, as far as I know, has only run on processors which physical su= pport
>for overflow detection (Alpha, VAX). So this is not a very useful proof= point
>for the significant number of processors that do not have such hardware=
>support.

The vast majority of processors, including the x86 family, have such hardwa= re
support.

>> =A0 =A0 =A0 =A02. =A0Detection of integer overflow conditions was = part of John Reid's
>> ENABLE block
>>proposal in 1994.
>
>John was proposing a language feature;
> he didn't have the burden of actually implementing it,
> so again this example
>proves nothing germane to Bill's objections.

John's ENABLE block was not shot down by people raising objections to i= nteger
overflow detection.

>Look at current GPU architecture manuals and hardware specifications fo= r
>examples of compute engines for which such handling could prove quite c= ostly
>(indeed, making moving computation off the CPU possibly pointless). GPU= s are
>similar (in many ways) to the old FPS style array processors and Cray s= tyle
>vector machines (just not nearly as polished or easy to program).
>
>I'm not saying that these aren't useful or interesting language= features. But
>those without any "skin the game" w.r.t. >implementing eit= her the hardware or
>software should not blithely ignore the costs proposed.

(1) No-one is blithely ignoring anything.
(2) I do in fact know what it costs in hardware and software; in hardware t= he
costs are not zero but they are miniscule compared to many other cute featu= res
that are being implemented.
(3) I have in fact implemented it in software without using the hardware support.

Or the snarkier but more amusing:

"Losing a rocket on the launch pad: a few billion dollars.
Being able to brag about your GPU: priceless."

Cheers,
--
................................Malcolm Cohen, Nihon NAG, Tokyo.

_______________________________________________
J3 mailing list
J3@mailman.j3-fortran.org<= br> http://mailman.j3-fortran.org/mailman/listinfo/j3

--f46d04446b0b273d5b04d38992a2--