Subject: hpff: Early opionions about DEC F90 and HPF in general

From: [email-masked] (Jason Taylor)
Date: Sat, 11 May 1996 13:38:49 -0400 (EDT)

---------------------------------------------------------------------------
[email-masked] is a mailing list for announcements related to High
Performance Fortran.  Instructions for adding or deleting yourself
from this list appear at the bottom of this message.
---------------------------------------------------------------------------

SUMMARY OF THIS MESSAGE: In my opinion, DEC's F90 HPF must have been
written by computer science majors, because it, and to a lesser extent
HPF in general, is NOT geared toward simple implementation of the most
common real-world applications of Fortran.

DETAILS: I got DEC's HPF F90 documentation kit yesterday.  From page
6-3 of D.H.P.F.90:

 "For new code, HPF is generally useful in the following cases:

  o Problems utilizing iterative solution methods
  o Signal processing
  o Image processing
  o Modeling
  o Grid-based problems in general
  o In general, most problems expressible as operations on large arrays"

	Reading that pretty much solidified my very negative opinions
as to how simple writing my programs using DEC's HPF to take advantage
of multiprocessing would be.  You see, the above is mostly geared
toward problems that manipulate array elements.  But I am not writing
programs that do time-evolution with very large arrays, etc.  Most of
my programs spend their cpu time under a top level DO loops which in
many cases just calculate a complicated function f(x) where, e.g.,
x=x_i and i=1,100.  Frequently, to evaluate f(x), I do a two- or
three-dimensional integration.  Thus the actual lines of code in the
main program that represent f(x) is generally quite small.  

	Let me be more precise.  The following is a real-world example
of such code.  The main block of this program is 1000 lines or so.
The code was written in RATFOR.  In the code, first, several variables
are setup.  Then a DO loop starts.  Then the integration routine QAGS
is called.  Then the results are printed out.  On a 277 MHz alpha
processor, each iteration (of I) takes ~5 seconds to evaluate, for a
total time of ~200 seconds.

...  (many setup statements removed)
#The following steps through the values of Vz and integrates over r.
Vzmax=1E5; Vzmin=50
IRES = 40  # IRES =(#of steps in Vz>1 plot).
VzSCALE=IRES/LOG(Vzmax); IMIN=INT(LOG(Vzmin)*VzSCALE)
Ithelpres=IRES-IMIN+1
Vzlast=Vzmax;dLdVzlast=0.
DO I=IRES,IMIN,-1
{Vz=(exp(I/VzSCALE)-exp(IMIN/VzSCALE))
 Rmax=Rmin
 While ((Sqrt(-2*(PHI(Rmax)))>Vz)&(Rmax<Rc/1.1)) {Rmax=Rmax*1.1}
 CALL QAGS(FrEXP,DLOG(Rmin),DLOG(Rmax),EPSABS,EPSREL,RESULT,ABSERR,INEVAL,IER)
 IF (IER.NE.0) {WRITE(6,*)'"RERROR!;ABSERR,INEVAL,IER="',ABSERR,INEVAL,IER}
 dLdVz=RESULT*sigma*2*PI/(Lumb/Lumi)
 #In units of 1/(km/sec);sigma=1km/sec=>neednt mult.
 WRITE(2,12)Vz*sigma,dLdVz,Lumb,INEVAL,ILASTVNEVAL,dLdVz*ABSERR,
  Rmax,Rmin,il*1.
 WRITE(6,14)Vz*sigma,dLdVz,Lumb,INEVAL,ILASTVNEVAL,IER,dLdVz*ABSERR,
  Rmax,Rmin,il*1.
 WRITE(14,12)dLdVz                                       #redlp.d
} # I
...  (many other statements removed)

Notes: (1) In theory, the above code should be `embarrassingly' simple
to parallelize; each value of dLdVz(Vz(I)) is independent from the
others.  (2) In normal F77 (after RATFOR preprocessing completes),
there are no arrays here.  (3) Almost all of the FORTRAN programs I
write are very similar in nature.  [Realize, there are SEVERAL points
where a code can be parallelized, and speed-wise it probably doesn't
matter too much which point is selected, so long as it is not at such
a `low' or `detailed' level that inter-processor communication
bandwidth becomes relevant.]

	I was thinking that I should be able to add one !HPF$
INDEPENDENT line to my code.  Ideally, the compiler should be able to
figure out the rest, since the above case is so simple.

	Instead, the manuals state that (1) the !HPF$ INDEPENDENT
command is not yet implemented.  (2) I must move the above lines into
a new "PURE" subroutine.  (3) I must add the necessary common blocks
such that the various functions and initialization variables are
passed to the new subroutine.  (4) I must convert the code to use
arrays, making, I presume, dLdVz(Vz) an array [dLdVz(I)].  (5) I must
replace the DO statement with the FORALL statement.  (6) I must add a
DISTRIBUTE statement describing how the target array is to be
distributed across the microprocessors.

	This is not just a lot of work, it is against the fundamental
principles of elegant TOP-DOWN programming.  If I am misunderstanding
the manuals, please correct me.  But it would appear to me that I will
end up making the situation MUCH more complicated than it really is.
Why?  Why?

	If I was REALLY young and willing to do this, I wouldn't be
using F90; I'd probably be using C.  So from a sales perspective, I
would have thought that there is good reason to make the transition to
F90 from F77 simple and painless as possible.  But I am finding this
transition not only to be painful, but even a step backward from what
I am used to.

	I can only speculate as to why the very typical above type of
program is not handled easily by DEC HPF90.  I suppose that most
parallel benchmarking programs of interest to ex-computer-science
majors require high inter-processor bandwidth.  Perhaps that is what
the software designers are concerned with (passing of large arrays,
etc.)  However, most non-time-evolution-like codes that take
significant computer time, such as the one above, should not require
significant cross-cpu bandwidth.  (Namely, a minimum of only 1000
bytes every second.)  THEY should be parallelizable without any
significant effort by the programmer.  But I am finding that this is
not the way HPF is being designed.  How sad.  

Comments anyone?

Regards,
Jason
-- 
Jason A. Taylor
Grad. Research Asst.  
Dept. of Physics University of Maryland 
USA
---------------------------------------------------------------------------
To (un)subscribe to this list, send mail to [email-masked].  Leave
the subject line blank, and in the body put the line
(un)subscribe <email-address>
---------------------------------------------------------------------------

---

From: [email-masked] (Erik D'Hollander)
Date: Mon, 13 May 1996 17:29:05 +0100

>common real-world applications of Fortran.

You are right when you assume that HPF is more complex than f77. The 
reason is that HPF (at this moment) is geared towards distributed 
computer platforms, where the communication is a bottleneck. Therefore 
HPF contains directives which allow the user to specify which data 
belongs together. An "intelligent" HPF-compiler will use these 
directives to generate good code and more importantly minimal 
communication overhead.

HPF is not a language which "detects" the parallelism in the program. 
It even doesn't detect the vectorizable loops, i.e. you have to write 
yourself the FORALL loops (for vector instructions) or the INDEPENDENT 
directive (for DOALL loops in which iterations run independently).

According to your experience, DEC didn't implement (yet) the 
INDEPENDENT directive. This is clearly what you need.

However, there exist parallelizing compilers, e.g. the FortranMP 
compiler of Sun Microsystems. There you can specify C$pardoall
as a synonym for INDEPENDENT. Also, the compiler is able to recognize 
simple forms of parallel loops. I ran yor code through that compiler
(after recoding it in f77) and found that your loop is automatically 
parallelized by FortranMP, provided the WRITE statements are removed.

Hope this helps.

Erik D'Hollander

RUG - Dept. of Electrical Engineering
Parallel Information Systems
St.-Pietersnieuwstraat 41
B-9000 Gent, BELGIUM
[email-masked]
---------------------------------------------------------------------------
To (un)subscribe to this list, send mail to [email-masked].  Leave
the subject line blank, and in the body put the line
(un)subscribe <email-address>
---------------------------------------------------------------------------