From: Nick Holford
Subject: [NMusers] Portland Group f77 compiler
Date:Tue, 06 Aug 2002 20:41:26 +1200
Does anyone have any experience with the Portland Group f77 compiler? I have been asked to
consider its use on a linux cluster. The current compiler is Gnu g77. I know from testing under
Windows that the Compaq Visual Fortran compiler (v 6.6A) appears to be numerically more robust
than g77.
http://www.pgroup.com/products/workpgf77.htm
Any comments on the Portland compiler?
--
Nick Holford, Divn Pharmacology & Clinical Pharmacology
University of Auckland, 85 Park Rd, Private Bag 92019, Auckland, New Zealand
email:n.holford@auckland.ac.nz tel:+64(9)373-7599x6730 fax:373-7556
http://www.health.auckland.ac.nz/pharmacology/staff/nholford/
Portland Group f77 compiler
From: "Bachman, William"
Subject:RE: [NMusers] Portland Group f77 compiler
Date:Tue, 6 Aug 2002 09:03:17 -0400
Nick,
You can't just leave it at that. What evidence do you have to support this
claim:
"I know from testing under Windows that the Compaq Visual Fortran compiler
(v 6.6A) appears to be numerically more robust than g77."
My experience has been to the contrary, the g77 compiler (with -O
optimization) behaved better with respect to floating point runtime errors
than the Compaq/Digital (with "/optimize:1 /fpe:0" optimization" which has
been used widely as the default). The results produced have been consistant
with output produced on UNIX systems using either g77 or Sun's compiler.
(A "better" (more robust) set of optimization options for Compaq/Digital
seems to be "/optimize:4 /fltconsistency /fpe:3" with respect to floating
point operations.)
regards,
Bill
From:Nick Holford
Subject:[NMusers] Compaq Visual Fortran compared to Gnu g77 compiler
Date:Wed, 07 Aug 2002 08:29:43 +1200
Bill,
I list below the results I got on Peter Bonate's valfit2 problem. The runs indicate the various
compilers and versions I tested with NONMEM V 1.1. g77 versions used -fno-backslash -O and df
versions used /fltconsistency /optimize:4 /fast.
This problem is numerically unstable and does not give a satisfactory solution with any
compiler. However, lower objective function values are produced by the df compiler versions
compared with the g77 compiler versions.
I have found the same behaviour on other examples and typically the Compaq Visual Fortran (df65
and later) will get lower objective function values than g77 on problems that do not converge
readily. If the problem converges then both compilers will converge at the same value and the
parameter estimates are essentially identical.
It is my interpretation of these results that g77 is unable to continue the search for a lower
objective because it loses precision. The compiler version is a factor that also needs to be
considered when reporting the results. Note that the Compaq version (df 6.6) is better than the
earlier Digital version (6.0A) and the g77 3.1 version is better than the earlier 0.5.25
version using the same criterion. I had reported this version specific issue earlier to nmusers
with a different problem (Re: [NMusers] Digital Visual Fortran vers 5.0 vs 6.6 March 20 2002).
#Run Sig Obj Errors
df66 2.5 8280.513 ROUNDING_ERRORS_(ERROR=134)
g7731 2.7 8313.35 ROUNDING_ERRORS_(ERROR=134)
g770525 2.5 8439.316 ROUNDING_ERRORS_(ERROR=134)
df60a . 8612.169
PROXIMITY_OF_LAST_ITERATION_EST._TO_A_VALUE_AT_WHICH_THE_OBJ._FUNC._IS_INFINITE_(ERROR=136)
From:Larry Bauer
Subject: Re: [NMusers] Portland Group f77 compiler
Date:Tue, 6 Aug 2002 13:30:00 -0700 (PDT)
I'm wondering what: ". . .Compaq Visual Fortran compiler (v 6.6A) appears
to be numerically more robust than g77. . ." means?
g77 is a standard open source compiler that is hard to beat for overall
value. It has always given me the same NONMEM results across Win 9x/NT/2k
and Linux platforms, which is another plus. So why pay for something that
is not a standard and only 30% faster on a benchmark (but not necessarily
on a real world problem)?
--Larry