Prev: Some matlab -> fortran translation
Next: minor typo in The Fortran 2003 Handbook?
From: News user on 26 Dec 2009 17:33
Hi there:

I have a rather long experience with scientific fortran programming
the last 20 years.
Recently I noticed the following problem with intel fortran em64t
compilers:

I have access to 3 differtent types of intel-CPU linux computers
running either intel ifort
(versions 9, 10 and 11) or g77:
(a) Pentimum 4 using intel 32-bit compilers
(b) Dual core Itanium 2 (linux ia64) using intel 64 compilers
(c) Intel Xeon 5300 quad core Processor (linux x86_64) using intel
em64t compilers

My fortran code solves over-determined systems using LAPACK DGELS
Least-Squares solver
while mainly I compile my code with ifort and MKL.

Machines (a) and (b) produce results identical to 9 significant digits
(s.d.) but machine (c)
produce results with only 4 s.d. Note that my code uses double-
precision and the systems
are well-conditioned, and thus I expect very limited round-off error,
and in particular,
agreement close to 14 s.d.

To investigate where is the problem with machine (c), I added LAPACK
and BLAS
double-precision subroutines into my code and compiled with ifort
(without MKL) and g77.
I got the same behavior.

Thus on machines (a) and (b), ifort (with or without MKL) and g77
produce results identical to
9 s.d. as does g77 on machine (c).
The problem is with ifort (with or without MKL) on machine (c) which
produces results
identical to 4 s.d. - this is a major issue with me since after
several thousand steps
the low-accuracy/high round-off error results in failure and the
running breaks down.

This problem seems to exist with Least-Squares solver DGELS - for
square systems using LU decomposition DGESV all machines and all
different compilations produce results identical to 9 s.d.

So, has anyone seen this issue/problem? Origin of problem? Any
possible solution?

--------------------------------------------------------------------------------------------------------------------------------------------
I do have an additional question:

Since my code uses double-precision and the systems are well-
conditioned,
I expect agreement close to 14 s.d - not the 9 s.d I get at the very
best.

In the past, on other types of processors (e.g AIX and SGI
workstations)
I was able to get 14 s.d. but not on current INTEL-based computers.

Is this a limit of the recent INTEL processors since this behavior
seems to be independent
of the compilers used (ifort or g77)?
--------------------------------------------------------------------------------------------------------------------------------------------

Many thanks in advance!

/PB









From: Richard Maine on 26 Dec 2009 17:48
News user <arapis(a)gmail.com> wrote:

> Machines (a) and (b) produce results identical to 9 significant digits
> (s.d.) but machine (c) produce results with only 4 s.d. Note that my code
> uses double- precision and the systems are well-conditioned, and thus I
> expect very limited round-off error, and in particular, agreement close to
> 14 s.d.

This being a Fortran newsgroup, it is probably a good place to ask
Fortran questions... but you don't show any Fortran. There are *LOTS* of
ways to accidentally lose precision. Some of them relate to
ill-conditioning, which you claim not to be an issue here, but some are
also simple matters of Fortran syntax. Without seeing code, there isn't
much I could offer other than random speculation.

To toss out one such random speculation, literal constants written in
default precision syntax are a reasonably common source of such
problems. Yes, the results of such things do vary from compiler to
compiler.

--
Richard Maine | Good judgment comes from experience;
email: last name at domain . net | experience comes from bad judgment.
domain: summertriangle | -- Mark Twain
From: steve on 26 Dec 2009 18:02
On Dec 26, 2:33 pm, News user <ara...(a)gmail.com> wrote:
>
> So, has anyone seen this issue/problem? Origin of problem? Any
> possible solution?
>

If you're using g77, then your code should be compatible with
ftnchek. Get a copy of ftnchek and fix all warnings. In particular,
see Richard Maine's post about literal constants.

Try using the compilers options for turning on warnings. With
g77 use -Wall -Wextra -Wsurprizing, among a host of other options
that I currently ron't remember.

LAPACK normally reports a condition number. Are you checking the
returned condition number against your expectations?

--
steve
From: News user on 26 Dec 2009 18:18
On Dec 26, 6:02 pm, steve <kar...(a)comcast.net> wrote:
> On Dec 26, 2:33 pm, News user <ara...(a)gmail.com> wrote:
>
>
>
> > So, has anyone seen this issue/problem? Origin of problem? Any
> > possible solution?
>
> If you're using g77, then your code should be compatible with
> ftnchek. Get a copy of ftnchek and fix all warnings. In particular,
> see Richard Maine's post about literal constants.
>
> Try using the compilers options for turning on warnings. With
> g77 use -Wall -Wextra -Wsurprizing, among a host of other options
> that I currently ron't remember.
>
> LAPACK normally reports a condition number. Are you checking the
> returned condition number against your expectations?
>
> --
> steve


Richard and Steve:

I realized that I forgot to mentioned some details on my code:

I use f77 fortran and I have double-checked my code with ftnchek;
and yes I always write very carefully using double precision constants
(e.g. 3.5d0) and all my real variables are defined to be real*8.
(The code is quite complicated and long to be included in a message.)

Note that on machine (c) g77 works ok - it is the
intel ifort em64t compiler which produces the low 4 s.d. agreement.
From: Tim Prince on 26 Dec 2009 20:00
News user wrote:
> On Dec 26, 6:02 pm, steve <kar...(a)comcast.net> wrote:
>> On Dec 26, 2:33 pm, News user <ara...(a)gmail.com> wrote:
>>
>>
>>
>>> So, has anyone seen this issue/problem? Origin of problem? Any
>>> possible solution?
>> If you're using g77, then your code should be compatible with
>> ftnchek. Get a copy of ftnchek and fix all warnings. In particular,
>> see Richard Maine's post about literal constants.
>>
>> Try using the compilers options for turning on warnings. With
>> g77 use -Wall -Wextra -Wsurprizing, among a host of other options
>> that I currently ron't remember.
>>
>> LAPACK normally reports a condition number. Are you checking the
>> returned condition number against your expectations?
>>
>> --
>> steve
>
>
> Richard and Steve:
>
> I realized that I forgot to mentioned some details on my code:
>
> I use f77 fortran and I have double-checked my code with ftnchek;
> and yes I always write very carefully using double precision constants
> (e.g. 3.5d0) and all my real variables are defined to be real*8.
> (The code is quite complicated and long to be included in a message.)
>
> Note that on machine (c) g77 works ok - it is the
> intel ifort em64t compiler which produces the low 4 s.d. agreement.
You have carefully avoided showing your compiler options, not to mention
a code example. Note that compilers for linux x86_64 default to SSE2
code, with no automatic promotion of expressions to double precision,
while only the latest ifort for 32-bit has a similar default.
 |  Next  |  Last
Pages: 1 2 3 4
Prev: Some matlab -> fortran translation
Next: minor typo in The Fortran 2003 Handbook?