| << Chapter < Page | Chapter >> Page > |
When you compare this example with a PVM implementation of the same problem, you can see some of the contrasts between the two approaches. Programmers who wrote the same six lines of code over and over in PVM combined them into a single call in MPI. In MPI, you can think “data parallel” and express your program in a more data-parallel fashion.
In some ways, MPI feels less like assembly language than PVM. However, MPI does take a little getting used to when compared to PVM. The concept of a Cartesian communicator may seem foreign at first, but with understanding, it becomes a flexible and powerful tool.
One style of parallel programming that we have not yet seen is the broadcast/gather style. Not all applications can be naturally solved using this style of programming. However, if an application can use this approach effectively, the amount of modification that is required to make a code run in a message-passing environment is minimal.
Applications that most benefit from this approach generally do a lot of computation using some small amount of shared information. One requirement is that one complete copy of the “shared” information must fit in each of the processes.
If we keep our grid size small enough, we can actually program our heat flow application using this approach. This is almost certainly a less efficient implementation than any of the earlier implementations of this problem because the core computation is so simple. However, if the core computations were more complex and needed access to values farther than one unit away, this might be a good approach.
The data structures are simpler for this approach and, actually, are no different than the single-process FORTRAN 90 or HPF versions. We will allocate a complete
RED and
BLACK array in every process:
PROGRAM MHEAT
INCLUDE ’mpif.h’INCLUDE ’mpef.h’
INTEGER ROWS,COLSPARAMETER(MAXTIME=200)
PARAMETER(ROWS=200,COLS=200)DOUBLE PRECISION RED(0:ROWS+1,0:COLS+1),BLACK(0:ROWS+1,0:COLS+1)
We need fewer variables for the MPI calls because we aren’t creating a communicator. We simply use the default communicator
MPI_COMM_WORLD . We start up our processes, and find the size and rank of our process group:
INTEGER INUM,NPROC,IERR,SRC,DEST,TAG
INTEGER S,E,LS,LE,MYLENINTEGER STATUS(MPI_STATUS_SIZE)
INTEGER I,R,CINTEGER TICK,MAXTIME
CHARACTER*30 FNAMEPRINT *,’Calling MPI_INIT’CALL MPI_INIT( IERR )
CALL MPI_COMM_SIZE( MPI_COMM_WORLD, NPROC, IERR )CALL MPI_COMM_RANK( MPI_COMM_WORLD, INUM, IERR)
CALL MPE_DECOMP1D(COLS, NPROC, INUM, S, E, IERR)PRINT *,’My Share ’, INUM, NPROC, S, E
Since we are broadcasting initial values to all of the processes, we only have to set things up on the master process:
* Start ColdIF ( INUM.EQ.0 ) THEN
DO C=0,COLS+1DO R=0,ROWS+1
BLACK(R,C) = 0.0ENDDO
ENDDOENDIF
As we run the time steps (again with no synchronization), we set the persistent heat sources directly. Since the shape of the data structure is the same in the master and all other processes, we can use the real array coordinates rather than mapping them as with the previous examples. We could skip the persistent settings on the nonmaster processes, but it doesn’t hurt to do it on all processes:
Notification Switch
Would you like to follow the 'High performance computing' conversation and receive update notifications?
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|