[Pympi-users] Where should pyMPI be going????

[Pat M. <pat...@ll...>]

Peter wrote:
 > pythonic API (everything is done via methods of communicator objects)

Just a note that pyMPI does it that way too.  I "hoist" methods off
of the WORLD communicator up and shove them in to the module to
look like functions.  This is done to ease the transition of C and
FORTRAN programmers [who already know MPI].  Then the code looks a lot
like procedural MPI e.g.

MPI_Bcast(....)               |    n = mpi.bcast(local)
MPI_Barrier(MPI_COMM_WORLD)   |    mpi.barrier()
MPI_Allreduce(... MPI_SUM)    |    all = mpi.allreduce(local,mpi.SUM)

If you like a more objecty model, you can use the communicators and their
methods.  E.g.

# Split into two teams
red = mpi.WORLD.split(range(0,mpi.size,2))
black = mpi.WORLD.split(range(1,mpi.size,2))

if red is not None:
   # Must be RED
   r = red.bcast(r0)
else:
   # Must be black!
   b = black.bcast(b1)
mpi.WORLD.barrier()

* * * * * * * *
On related business...

What features do you think I should be working on improving as the Python MPI
field becomes more competitive?

My current priority list is:

1) Direct [non-pickled] communication for Numarray and Numeric arrays
2) A "remote-communicating-objects" layer [one-sided, interrupting
    remote method calls]
3) SIMD support

Cheers,

Pat

-- 
Pat Miller | (925) 423-0309 | http://www.llnl.gov/CASC/people/pmiller

What hunger is in relation to food, zest is in relation to life.  -- Bertrand
Russell, philosopher, mathematician, and author (1872-1970)