[mpich-discuss] MPI Implementation on 1 module
Gulshan Singh
sgulshan at gmail.com
Wed Jan 5 09:56:42 CST 2011
We are implementing MPI on a module of a multi-module code. We created MPI
enhanced module, created its object file and linked it with the existing
object files from other modules. The MPI enhanced modules is performing as
expected. We are also getting good speed-up for the module. But the problem
we are facing is that the slave nodes are not stopping the computation after
the MPI enhanced module work is finished. We were expecting that
MPI_FINALIZE(err) command will stop all the nodes expect the master node.
The Call MPI_FINALIZE(err) does not stop the additional processors. What is
the solution for this problem?
Gulshan
On Tue, Dec 14, 2010 at 4:51 AM, Nicolas Rosner <nrosner at gmail.com> wrote:
> Hello Gulshan,
>
> I'm assuming you meant more or less the following:
>
> - you have a program spanning multiple compilation units and/or libs
> and
> - you would like to MPI-enable just one of said units or modules
> and
> - any necessary IPC/comm/sync between the MPI-ized unit and the rest
> is addressed by separate mechanisms (other than MPI)
>
> If so, sure, as long as you have the source code for that particular unit
> or module, you should be able to limit any MPI compile/link-dependency of
> your system to the one module that actually uses MPI calls.
>
>
> > There are more than 10 modules in the software we are trying to modify to
> > improve the speed. We know that the most time is taken by only one
> module.
>
> Do these modules map to sequential stages of a workflow/pipeline? Is that
> one module one such stage? Is it currently invoked in a call-return way?
>
>
> > So MPI starts when the particular module is called and
> > the MPI collapses as soon as the computation in the module is finished.
>
> What you describe sounds essentially like a sequential program that, at
> some point --or perhaps every now and then-- needs to launch a parallel,
> MPI-enhanced subroutine/subprocess, wait until it's done, then move on..?
>
> If so, this is certainly possible, assuming your resource allocation
> plays along (ie the machines are always there for you when you need them,
> etc).
>
> HTH, just guessing; good luck! N.
> _______________________________________________
> mpich-discuss mailing list
> mpich-discuss at mcs.anl.gov
> https://lists.mcs.anl.gov/mailman/listinfo/mpich-discuss
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/mpich-discuss/attachments/20110105/fe388e3f/attachment.htm>
More information about the mpich-discuss
mailing list