Newsgroups: comp.parallel.mpi
From: patrick@walt.CS.MsState.Edu (Patrick G. Bridges)
Subject: Re: MPI for shared memory machines?
Organization: Mississippi State University CS Dept.
Date: 16 Aug 1994 02:33:39 GMT
Message-ID: <PATRICK.94Aug15213347@walt.CS.MsState.Edu>

>>>>> "LB" == Luis Barriga <luis@quipu.electrum.kth.se> writes:
In article <LUIS.94Aug10181948@quipu.electrum.kth.se> luis@quipu.electrum.kth.se (Luis Barriga) writes:


    LB> In article <PATRICK.94Aug5094411@walt.CS.MsState.Edu>
    LB> patrick@walt.CS.MsState.Edu (Patrick G. Bridges) writes: Well,
    LB> it seems like overkill. MPI on top of P4 which is on top of
    LB> SYSV which itself is a mess.

    LB> Well all these machines are message passing ....

True, but MSU/ANL MPI (more acronyms thatn you can shake a stick at :-) )
also runs on the KSR and SGI multiprocessors using shared memory...

    LB> We have different views of shared memory, I think. For you it
    LB> is something like system V provides or what can be achieved by
    LB> several UNIX processes using mmap(). In my case, shared memory
    LB> for threads is the memory within a single UNIX address
    LB> space. I can't see headaches since all sync primitives are
    LB> provided by Solaris. NO sockets are not feasible for fine
    LB> granularity processing.

It would seem to me that you would have to be concious of the shared
address space when you wrote the program to avoid things like naming
and shared variable confilicts... Your program would have many of the
synchronoization headaches of multi-threaded programs, or am I missing
something?  SIMD programs especially would be hard to do in this
system. 

The speed would be blazing, though, since you're in one address space,
and (if you have user level threads), entry to the kernel may not even
be necessary to context switch. Why not just write with shared memory,
threads, and locks/semaphores, though?

I agree that a threads implementation of MPI would be _very fast_, but
wouldn't programmers in the system have to take special
shared-variable synchronization and naming precautions that they
wouldn't have to take in seperate-process implementations? And since
you're already dealing with these headaches (unless I'm missing
something), why not just use threads and locks/semaphores and shared
memory anyway?
--
*** Patrick G. Bridges  		patrick@CS.MsState.Edu ***
***      PGP 2.6 public key available via finger or server     ***
***             PGP 2.6 Public Key Fingerprint:		       ***
***      D6 09 C7 1F 4C 18 D5 18  7E 02 50 E6 B1 AB A5 2C      ***
***                #include <std/disclaimer.h>		       ***

