Hello,
Thanks for the input Jeff. The problem that I'm trying to tackle is
easily parallelizable ... it consist of a singe graph were an
operation is performed for each vertex. Apart from checking for
duplicate results (some thing that can be done at the very end), the
operation for each vertex runs independently from the others.
This should make it very simple to parallelize. I once read that such
problems are categorized as "embarrassingly parallel".
Being a novice, the purpose of my original message was to get ideas as
to how I could send/receive arbitrary sized lists between processes.
I've taken Ming's approach and so far I'm making good progress with my task.
Thank you all for your help,
../Kaveh
On 4/15/05, Jeff Squyres <jsquyres_at_[hidden]> wrote:
> MPI is more about message passing than explicitly sharing data (in a
> shared memory or DSM sense). Keep in mind that MPI may *use* shared
> memory to send and receive messages, but that underlying protocol
> transport is not exposed to the user.
>
> As someone else replied in this thread, one way to handle linked lists
> is to send them to the process that you're working with. However, it
> really depends on what you're trying to do. If you really need to
> concurrently *share* the data between two threads or processes, MPI is
> probably not the right tool. Be aware of all kinds of locking and bus
> contention issues if you decide to use a pure shared memory approach
> (and this list is probably not the right place for help for that), and
> that you'd have to effect your own off-node communication in this
> approach.
>
> Another approach is to use threads on a single machine (your question
> implies that you have a cluster of SMPs) and MPI for off-machine
> communication. There's limitations on this, however, mainly because
> LAM is a single-threaded implementation of MPI and can't handle
> multiple threads in its library simultaneously. Search the list
> archives for some information on this.
>
> A more MPI-like approach would be to split up the data and have one
> process handle its portion of the data, and synchronize "border values"
> with peer processes. How you split up this data and synchronize the
> border values is totally problem-dependent, of course. But since your
> goal is to run across a cluster, you might want to look at the problem
> you're trying to solve and see if it's easily parallelizable first
> (e.g., how would you split up the data across multiple nodes, work on
> them more-or-less independently, etc.).
>
> Hope this helps.
>
|
