Very Computer

(sorry about the first aborted post)

Hi,

Currently I am a RedHat 4.1 user on a Pentium 166 MMX.  I am running some
floating point intensive molecular dynamics Fortran code compiled under
g77 2.7.2.3 and am hoping to move to an Alpha processor based computer for
a performance boost.  I would very much appreciate any opinions on how g77
compares to Digital Fortran with respect to performance on alpha cpu's.  I
would prefer to stick with Linux/g77 after switching to the alpha, and am
wondering if and how much performance will be compromised as compared to
Digital UNIX/Fortran.

I realize this message does not contain too much "meat" regarding what
type of algorithms the code uses, but as I am just now beginning to take a
look at the guts of the code I am afraid I cannot offer much more to go
on.

Perhaps someone can address with what types of algorithms or code
structure either of the two Fortran compiliers excel or do not excel.
(or any other Fortran 77 compilers for alpha for that matter...)

Thank you in advance.

Yours,
Olgun Guvench

Quote:> Currently I am a RedHat 4.1 user on a Pentium 166 MMX.  I am running some
> floating point intensive molecular dynamics Fortran code compiled under
> g77 2.7.2.3 and am hoping to move to an Alpha processor based computer for
> a performance boost.  I would very much appreciate any opinions on how g77
> compares to Digital Fortran with respect to performance on alpha cpu's.  I
> would prefer to stick with Linux/g77 after switching to the alpha, and am
> wondering if and how much performance will be compromised as compared to
> Digital UNIX/Fortran.

Don't bother with the combination g77-0.5.21+gcc-2.7.2.3 for _speed_.

Quote:> Perhaps someone can address with what types of algorithms or code
> structure either of the two Fortran compiliers excel or do not excel.
> (or any other Fortran 77 compilers for alpha for that matter...)

1. Your code does a lot of REAL -> INTEGER or INTEGER -> REAL conversions.
2. It does a lot of sqrt's (Digital's compiler uses a special 4-sqrts-
   at-a-time run time library routine).
3. Your code has a lot of array accesses that are a constant number
   of bytes apart in loops, like (note the B's):

      A(1) = 0.0
      DO I = 2, N
         A(I) = B(I) + B(I-1)
      ENDDO

   egcs/g77 tends to spend too many registers on this, which hurts in larger
   loops.  Work is underway on this shortcoming.

HTH,

--

Saturnushof 14, 3738 XG  Maartensdijk, The Netherlands
Phone: +31 346 214290; Fax: +31 346 214286

A similar thread came up in comp.arch about a 4 months ago,
in light of the recognition that most MD programs really
need sqrt(1/rSqrd).  It was pointed out that the standard
Newton's method formulation is easily cast in 1/rSqrd,
removing a lot of unnecessary calculation (in particular,
the division).  Terje Mathisen was tracking the various
methods at that time, and indeed it was possible to
achieve quite a bit of register-level parallelism.

Not all MD methods may benefit by this approach, but it is
possible that a few carefully-selected hand optimizations
might overwhelm the differences among the compilers.

Christopher Grayce
Dept of Chemistry
UC Irvine
cgrayce at uci dot edu

But, the folks at Digital indeed do know their business, when
it comes to producing decent Fortran compilers anyway.  They
spent a fair amount of time and effort making sure their Fortran
compilers optimized properly for Alphas, using techniques that
the gcc/egcs back end doesn't know about yet (like true
loop prefetching/unrolling).  And they also made the
underlying run-time libraries fast in the critical places.
--

"Practice random senselessness and act kind of beautiful."

Chris
--
  When I die, please cast my ashes upon Bill Gates
   --for once, let him clean up after me!