From owner-sc22wg5@open-std.org Thu Sep 23 16:02:10 2004 Return-Path: X-Original-To: sc22wg5-domo Delivered-To: sc22wg5-domo@ghz.klid.dk Received: by ghz.klid.dk (Postfix, from userid 521) id 32C3C37608; Thu, 23 Sep 2004 16:02:10 +0200 (CET DST) X-Original-To: sc22wg5@open-std.org Delivered-To: sc22wg5@open-std.org Received: from dkuug.dk (ptah.dkuug.dk [195.215.30.66]) by ghz.klid.dk (Postfix) with ESMTP id 85D9D37608 for ; Thu, 23 Sep 2004 16:02:07 +0200 (CET DST) Received: from out3.mx.klmz.mi.voyager.net (out3.mx.klmz.mi.voyager.net [207.89.252.198]) by dkuug.dk (8.12.10/8.9.2) with ESMTP id i8NE08jH091772 for ; Thu, 23 Sep 2004 16:00:11 +0200 (CEST) (envelope-from Craig_Dedo@execpc.com) Received: from [127.0.0.1] (d19.as14.nwbl1.wi.core.com [169.207.88.19]) by out3.mx.klmz.mi.voyager.net (Postfix) with ESMTP id DAD4977268; Thu, 23 Sep 2004 09:49:39 -0400 (EDT) Message-ID: <4152D467.9060806@execpc.com> Date: Thu, 23 Sep 2004 08:49:27 -0500 From: Craig Dedo Reply-To: Craig Dedo Organization: Elmbrook Computer Services User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax;nscd1) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Bernard Pichon Cc: WG5 , Alain Noullez , Steve Lionel Subject: Re: (j3.2004) (SC22WG5.3179) Forwarded message: Re: Why (standard conforming OR platform implementation) References: <20040923083229.F08E437607@ghz.klid.dk> In-Reply-To: <20040923083229.F08E437607@ghz.klid.dk> Content-Type: multipart/mixed; boundary="------------070006070705000308020908" X-Spam-Score: 0.609 () HTML_MESSAGE,HTML_TITLE_EMPTY Sender: owner-sc22wg5@open-std.org Precedence: bulk This is a multi-part message in MIME format. --------------070006070705000308020908 Content-Type: multipart/alternative; boundary="------------060607070802030403030109" --------------060607070802030403030109 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Dear Mr. Pichon: Your program is standard conforming. Unfortunately, you ran into a subtlety of the Fortran standard that is not very well known or understood. Short answer: How values are computed is beyond the scope of the Fortran standard. Details: Here are the gory details in case you are interested. One of the major exclusions from the scope of the Fortran standard is how a Fortran processor computes its values. This is specifically excluded in section 1.4. Here is the relevant text from the Fortran 95 standard: [Begin quote from F95 standard] 1.4 Exclusions This standard does not specify . . . (6) The physical properties of the representation of quantities and the method of rounding, approximating, or computing numeric values on a particular processor, [End of quote from F95 standard] Thus, each compiler is free to choose its own methods of internal representation and how to compute values. The Fortran compiler on the Alpha could do all of its work in single precision and the Fortran compiler on the Intel chip could do all of its work using Intel's 80-bit internal Floating-Point Unit (FPU) representation. That is in fact how things are done on these two platforms, if your program declares single-precision variables. The Alpha chip has direct hardware support for both 32-bit and 64-bit floating-point representations. Therefore, the Fortran compiler for the Alpha chip generates hardware instructions for 32-bit floating-point. In contrast, the Fortran compiler for the Intel chip generates the usual Intel floating-point instructions and performs the FP operations in the Intel FPU. The Intel FPU only uses Intel's own 80-bit internal FPU representation. When FP values are loaded into the Intel FPU, they are converted from their declared size and precision into the Intel 80-bit internal representation. When they are stored back into memory, they are converted from the Intel 80-bit representation back into their original representation. Thus, on the Intel chip, internal calculations always have the greatest possible accuracy. On the Intel chip, whether intermediate calculations are kept internal to the FPU registers or are stored back out to memory depends on the compiler and its switch settings. To find out the exact details of how a particular compiler performs its arithmetic and what precision(s) it uses, you will need to RTFM (Read The Fine Manual). This also means that you will need to examine this issue closely if you ever move a program from one platform to another. This caution includes any change in these variables: hardware, operating system, run time library, and compiler. The same vendor can quite legally use one method in its Fortran compiler on one system and a different method for its Fortran compiler on a different system. In fact, formerly DEC, formerly Compaq, now Intel has done exactly that with their Fortran compilers on the Alpha chip (both VMS and Unix) in contrast to the Intel chip (DVF --> CVF now IVF). While I have no inside information, my guess is that the reason was what hardware support was available for FP operations on the various chips. Hope this helps. John Reid wrote: > Date: Wed, 22 Sep 2004 14:48:30 -0400 > Message-ID: > <6E93844AE9173945878F42EB2DBB51B34B0A1D@hdsmsx402.amr.corp.intel.com> > X-MS-Has-Attach: > X-MS-TNEF-Correlator: > Thread-Topic: Why (standard conforming OR platform implementation) > Thread-Index: AcSgzs48GIa8BHSkSDmP8Mz7RH0vIQAA6nKg > From: "Lionel, Steve" > To: "Bernard PICHON" , > Cc: "NOULLEZ, Alain" > X-OriginalArrivalTime: 22 Sep 2004 18:48:31.0454 (UTC) > FILETIME=[C195AFE0:01C4A0D4] > X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) > X-Spam-Score: 0 () > > The problem you're having is due to the use of the Intel X87 floating > point registers where calculations involving single precision are > actually computed in double precision. For performance, intermediate > computations are kept in the registers as long as possible, which can > lead to slightly different (though better!) results compared to > computations that are rounded to single precision. > > CVF has a /fltconsistency switch which reduces the effects of this, but > it does not help with your program. Intel Fortran offers /Op which does > help and gives the result you're looking for, though at a penalty in > performance (as /fltconsistency does with CVF). > > The Alpha system is more "traditional" in that computations are always > carried out in the declared precision. > > The Fortran standard is rather vague when it comes to defining the > numerical results of computation. It does not even state that 2+2=3D4! > The CVF behavior is standard-conforming. > > Steve Lionel > Software Products Development > Intel Corporation > Nashua, NH=20 > > -----Original Message----- > From: Bernard PICHON [mailto:Bernard.Pichon@obs-nice.fr]=20 > Sent: Wednesday, September 22, 2004 2:11 PM > To: sc22wg5@dkuug.dk > Cc: NOULLEZ, Alain; Lionel, Steve > Subject: Why (standard conforming OR platform implementation) > > Dear Fortran ! > (expands in : Dear WG5 members, dear Lionel) > > This program seems to me standard conforming. > But I don't understand its (different) behavior > between Alpha platforms (with True64) for > which the result is OK (for me) > and Windows/Intel platforms (with CVF V6.6B) > with a (very) strange result (in my opinion). -- ---------- Sincerely, Craig T. Dedo 17130 W. Burleigh Place Internet: Craig_Dedo@execpc.com Brookfield, WI 53005-2759 Voice Phone: (262) 783-5869 USA Fax Phone: (262) 783-5928 "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -- Benjamin Franklin (1759) --------------060607070802030403030109 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Dear Mr. Pichon:
    Your program is standard conforming.  Unfortunately, you ran into a subtlety of the Fortran standard that is not very well known or understood.

    Short answer:  How values are computed is beyond the scope of the Fortran standard.

    Details:  Here are the gory details in case you are interested.

    One of the major exclusions from the scope of the Fortran standard is how a Fortran processor computes its values.  This is specifically excluded in section 1.4.  Here is the relevant text from the Fortran 95 standard:

[Begin quote from F95 standard]
1.4 Exclusions
This standard does not specify
       . . .
(6) The physical properties of the representation of quantities and the method of rounding, approximating, or computing numeric values on a particular processor,
[End of quote from F95 standard]

    Thus, each compiler is free to choose its own methods of internal representation and how to compute values.  The Fortran compiler on the Alpha could do all of its work in single precision and the Fortran compiler on the Intel chip could do all of its work using Intel's 80-bit internal Floating-Point Unit (FPU) representation.

    That is in fact how things are done on these two platforms, if your program declares single-precision variables. 

    The Alpha chip has direct hardware support for both 32-bit and 64-bit floating-point representations.  Therefore, the Fortran compiler for the Alpha chip generates hardware instructions for 32-bit floating-point. 

    In contrast, the Fortran compiler for the Intel chip generates the usual Intel floating-point instructions and performs the FP operations in the Intel FPU.  The Intel FPU only uses Intel's own 80-bit internal FPU representation.  When FP values are loaded into the Intel FPU, they are converted from their declared size and precision into the Intel 80-bit internal representation.  When they are stored back into memory, they are converted from the Intel 80-bit representation back into their original representation.  Thus, on the Intel chip, internal calculations always have the greatest possible accuracy. 

    On the Intel chip, whether intermediate calculations are kept internal to the FPU registers or are stored back out to memory depends on the compiler and its switch settings. 

    To find out the exact details of how a particular compiler performs its arithmetic and what precision(s) it uses, you will need to RTFM (Read The Fine Manual).   

    This also means that you will need to examine this issue closely if you ever move a program from one platform to another.  This caution includes any change in these variables:  hardware, operating system, run time library, and compiler.  The same vendor can quite legally use one method in its Fortran compiler on one system and a different method for its Fortran compiler on a different system.  In fact, formerly DEC, formerly Compaq, now Intel has done exactly that with their Fortran compilers on the Alpha chip (both VMS and Unix) in contrast to the Intel chip (DVF --> CVF now IVF).  While I have no inside information, my guess is that the reason was what hardware support was available for FP operations on the various chips.

    Hope this helps.

John Reid wrote:
Date: Wed, 22 Sep 2004 14:48:30 -0400
Message-ID: <6E93844AE9173945878F42EB2DBB51B34B0A1D@hdsmsx402.amr.corp.intel.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: Why (standard conforming OR platform implementation)
Thread-Index: AcSgzs48GIa8BHSkSDmP8Mz7RH0vIQAA6nKg
From: "Lionel, Steve" <steve.lionel@intel.com>
To: "Bernard PICHON" <Bernard.Pichon@obs-nice.fr>, <sc22wg5@dkuug.dk>
Cc: "NOULLEZ, Alain" <anz@obs-nice.fr>
X-OriginalArrivalTime: 22 Sep 2004 18:48:31.0454 (UTC) FILETIME=[C195AFE0:01C4A0D4]
X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang)
X-Spam-Score: 0 ()

The problem you're having is due to the use of the Intel X87 floating
point registers where calculations involving single precision are
actually computed in double precision. For performance, intermediate
computations are kept in the registers as long as possible, which can
lead to slightly different (though better!) results compared to
computations that are rounded to single precision.

CVF has a /fltconsistency switch which reduces the effects of this, but
it does not help with your program.  Intel Fortran offers /Op which does
help and gives the result you're looking for, though at a penalty in
performance (as /fltconsistency does with CVF).

The Alpha system is more "traditional" in that computations are always
carried out in the declared precision.

The Fortran standard is rather vague when it comes to defining the
numerical results of computation.  It does not even state that 2+2=3D4!
The CVF behavior is standard-conforming.

Steve Lionel
Software Products Development
Intel Corporation
Nashua, NH=20

-----Original Message-----
From: Bernard PICHON [mailto:Bernard.Pichon@obs-nice.fr]=20
Sent: Wednesday, September 22, 2004 2:11 PM
To: sc22wg5@dkuug.dk
Cc: NOULLEZ, Alain; Lionel, Steve
Subject: Why (standard conforming OR platform implementation)

Dear Fortran !
(expands in : Dear WG5 members, dear Lionel)

This program seems to me standard conforming.
But I don't understand its (different) behavior
  between Alpha platforms (with True64) for
      which the result is OK (for me)
  and Windows/Intel platforms (with CVF V6.6B)
      with a (very) strange result (in my opinion). 

-- 
----------
Sincerely,
Craig T. Dedo
17130 W. Burleigh Place             Internet:     Craig_Dedo@execpc.com
Brookfield, WI   53005-2759         Voice Phone:  (262) 783-5869
USA                                 Fax Phone:    (262) 783-5928

"They that can give up essential liberty to obtain a little temporary
    safety deserve neither liberty nor safety."  -- Benjamin Franklin
    (1759)
--------------060607070802030403030109-- --------------070006070705000308020908 Content-Type: text/x-vcard; charset=utf-8; name="Craig_Dedo.vcf" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="Craig_Dedo.vcf" begin:vcard fn:Craig Dedo n:Dedo;Craig adr:;;17130 W. Burleigh Place;Brookfield;WI;53005-2759;USA email;internet:Craig_Dedo@execpc.com tel;work:(262) 783-5869 tel;fax:(262) 783-5928 tel;home:(262) 783-5869 tel;cell:(414) 412-5869 x-mozilla-html:TRUE version:2.1 end:vcard --------------070006070705000308020908--