On Aug 11, 2005, at 11:18 AM, Michael Lees wrote:
> Does lam use polling or interrupts for its synchronous sending and
> receiving?
Polling.
It is probably better to categorize these are synchronous and
asynchronous message passing progress (vs. interrupts and polling) --
interrupts are one possible way of doing asynchronous progress, but
there are other methods as well.
> Is it configurable to use either? If so what is the default behaviour?
Err... sorta.
The default behavior is synchronous (polling). However, we do have one
transport (aka "RPI") that uses asynchronous progress called the "lamd"
RPI. Check out the FAQ on this (under "Running LAM/MPI Applications",
the questions "What is the lamd RPI?" and "Why would I use the lamd RPI
module (vs. other RPI modules)?"). The lamd RPI is slower than all the
others, but it can be a real performance boon to applications who truly
need asynchronous progress.
> I have a thread for performing asynchronous sending and receiving,
> something along the lines of...
>
> while(running){
> MPI_IRecv(&request)
> While(recvflag ==0){
> MPI_Test(request,recvflag)
> MPI_Send()
> yield()
> }
> yield()
> }
Wow, that's a lot of sending. :-)
> From reading a bit [1]:
> <snip>
> </snip>
>
> Now my application seems to satisfy all three of these, will I have
> improved performance using interrupts?
It's possible. "Never say never or always", right? The truth is that
it's very much an application-specific question. This gets more
complex if you are oversubscribing your processors.
> I have particular problems when there are multiple mpi processes per
> node. If you have a lot of MPI processes per node will interrupts
> perform better?
Again, this is unfortunately going to be application-dependant. It
really depends on what your app is doing, how often your processes are
being swapped in for execution (in the oversubscription case), etc.
The best thing you can do is try them both and see what happens. With
LAM, this is a simple option to mpirun:
mpirun -ssi rpi lamd ....
tells it to use the lamd RPI, for example. So you don't need to
recompile, etc.
--
{+} Jeff Squyres
{+} jsquyres_at_[hidden]
{+} http://www.lam-mpi.org/
|