[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re:[ccp4bb]: Porland Group Fortran compilers - the 99% solution



***  For details on how to be removed from this list visit the  ***
***    CCP4 home page http://www.dl.ac.uk/CCP/CCP4/main.html    ***

A followup, with thanks to Clemens Vonrhein

From: Clemens Vonrhein <vonrhein@GlobalPhasing.com>
[heavily trimmed]

> here are my experiences with the Portland Group Compiler:
> 
> I usually set various environmental variables that will then be used
> by the configure script instead of the default ones. Here is what I
> use for the pgf77 compiler:
> 
>     % FC="/usr/pgi/linux86/bin/pgf77"
>     % XFFLAGS="-Mnosecond_underscore -Wl,-rpath,$CLIB"
>     % FOPTIM="-O2 -Munroll -tp px -Kieee -Minform,inform"
>     % F77=$FC

If I read the pgf77 manual correctly, -O2 already included -Munroll
Also, I specified the -g77libs flag because the manual seemed to
indicate this would be necessary in order for g77/gcc programs to
link to the resulting shared libraries.

> > 	1) The lsqkab_exam failure is due to the program attempting to 
> > 	open the same file twice:  HKLIN1 rnase.pdb HKLIN2 rnase.pdb
> > 	I can understand why this would be illegal without the READONLY
> > 	flag, but I _thought_ that I had correctly added READONLY support.
> > 	So I don't understand why it's still failing.  Just as a side note,
> > 	I don't understand how this example ever works on a system that 
> > 	doesn't support READONLY.
> 
> As far as I can tell it has nothing to do with READONLY: the Fortran77
> standard states that only 'one unit at a time can be connected to a
> file'. The lsqkab example tries to open the same file on two different
> units (XYZIN1 and XYZIN2). It's possible, that most other compilers
> are a bit more clever and can handle this - but it's clearly a
> non-standard assumption. BTW: the Lahey compiler chokes on that too ...

Aha. Yes, you are correct; I see this is specified in the 1995 ANSI
document.  I am overly influenced by long-term experience with DEC
compilers, going back to (ahem, let's just say pre-PDP11 days). Starting
with VAX Fortran, the OPEN statement supported READONLY and SHARED 
attributes to allow the same file to be opened multiple times.
The Portland compiler kept VAX/VMS compatibility with regard to READONLY,
but not SHARED.

> > 	3) The refmac_tls_exam error is another file open failure.
> 
> Have you put in the latest patches from the CCP4 problems page?
> Especially:
> 
> *** 3644,3649 ****
> --- 3644,3651 ----
>         ENDIF   
>         GOTO 10
>    999  CONTINUE
> +       CLOSE(ISCRB)
> +       ISCRB = 0
>         RETURN
>         END

Thanks. That takes care of it nicely.
So now it's a 100% solution :-)

> BTW: here are some timings running all scripts in
> $CCP4/examples/unix/runnable.
> 
> 1. Athlon 1.1GHz, RedHat 7.0:
> -----------------------------------
>   
>   1.1. default g77/gcc (gcc 2.95.3) linux compilation:
> 
>      real time =    886.0
>      user time =    781.3
>       sys time =     31.4
>  
>   1.2. Portland Group Compiler (see flags above):
>  
>      real time =    851.8
>      user time =    780.1
>       sys time =     25.7

For what it's worth, I get

  3. Athlon 1.1GHz, Mandrake 8.0(beta2)

  3.1 Portland Group Compiler   (pgf77 -O -g77libs)

	real time =   699.0
	user time =   676.6
	 sys time =    17.2

So my build runs 13% faster on a similar machine.
Maybe this is due to your specification of -Kieee, maybe it's -tp px,
or it could be hardware differences or even the newer system libraries.

On the other hand, ...

  3.2 Default g77/gcc (gcc 2.96)

	refmac dumps core in arp_warp.exam and refmac.exam
	compar.exam and fofcmap.exam fail
	refmac5_ goes into apparent infinite loop (I killed it after 30 min)

	Re-ran the non-refmac tests  (not very useful, of course)

	real time = 362
	user time = 348
	 sys time =  12.8

So it looks like using the default "./configure linux" is not an option under
Mandrake 8.0.  I don't know if it's gcc 2.96 or what, and I'm not
inclined to spend any more time on it now. But maybe we can anticipate
many cries for help if and when people upgrade, assuming this isn't
some general gcc problem that is fixed before the final release.

				Ethan A Merritt