Prev: Any libraries for vector mask and vector population count?
Next: Preventing file sharing
From: Greg Lindahl on 8 Apr 2008 14:38
In article <47fb14a1$1(a)news.auckland.ac.nz>,
Gib Bogle <g.bogle(a)auckland.no.spam.ac.nz> wrote:

>Hi Greg. I'm not sure what you mean by "extra work". I am creating my
>own structured type with MPI_TYPE_STRUCT() and MPI_TYPE_COMMIT().

That's the extra work I was referring to.

Most people's natural inclination is to just pass the derived type
directly into MPI_Send(), which doesn't work. But it ought to.

-- greg


From: Craig Powers on 8 Apr 2008 23:30
Gib Bogle wrote:
> Craig Powers wrote:
>> Gib Bogle wrote:
>>> The user's guide for MPICH says that the "MPI module does not provide
>>> full Fortran 90 support; in particular, interfaces for the routines,
>>> such as MPI_Send, that take choice arguments are not provided." From
>>> my point of view this is regrettable, since I want to send and
>>> receive data of derived type. I will be using Intel Visual Fortran
>>> 9 on Windows, and possibly Linux. If someone has used the Intel
>>> compiler with MPICH, and has experience with the choice arguments,
>>> I'd like to know whether they just generate compiler warnings or fail
>>> to compile. Thanks in advance.
>>
>> I've done derived types with ifort 9 and MPICH 2 (although I
>> subsequently switched to LAM and OpenMPI), but that was via mpif.h and
>> not the module. MPICH 1 is problematic due to the lack of some of the
>> MPI 2 inquiry functions.
>
> Just out of interest, what are the pros (& cons) of OpenMPI vs. MPICH-2?

The issue I had with MPICH-2 was stability: sometimes it would refuse to
start a job (for no reason that I could figure out), and sometimes in
the middle of a job, it would crash out with a cryptic message about
losing one of the daemons (which would be supremely annoying if it were
to happen 3/4 of the way through a week-long job).

In contrast, LAM and subsequently OpenMPI have been exemplary. An
additional benefit with OpenMPI is that it has good integration with Sun
Grid Engine, which is what we use to manage jobs on our group's cluster
and is also what the university uses on its campus-wide high-performance
computing resources. LAM has some issues with process cleanup, where if
you're not careful you get zombie jobs hanging out on the nodes.

I haven't attempted to benchmark relative performance.
From: Craig Powers on 8 Apr 2008 23:32
Greg Lindahl wrote:
> In article <47fb14a1$1(a)news.auckland.ac.nz>,
> Gib Bogle <g.bogle(a)auckland.no.spam.ac.nz> wrote:
>
>> Hi Greg. I'm not sure what you mean by "extra work". I am creating my
>> own structured type with MPI_TYPE_STRUCT() and MPI_TYPE_COMMIT().
>
> That's the extra work I was referring to.
>
> Most people's natural inclination is to just pass the derived type
> directly into MPI_Send(), which doesn't work. But it ought to.

I think for that to work, there would need to be tighter integration of
MPI with the compiler than there is now, so that MPI would know the
information that is now given to it using the MPI_TYPE_* functions.
From: Gib Bogle on 9 Apr 2008 16:39
Craig Powers wrote:
> Gib Bogle wrote:
>> Craig Powers wrote:
>>> Gib Bogle wrote:
>>>> The user's guide for MPICH says that the "MPI module does not
>>>> provide full Fortran 90 support; in particular, interfaces for the
>>>> routines, such as MPI_Send, that take choice arguments are not
>>>> provided." From my point of view this is regrettable, since I want
>>>> to send and receive data of derived type. I will be using Intel
>>>> Visual Fortran 9 on Windows, and possibly Linux. If someone has
>>>> used the Intel compiler with MPICH, and has experience with the
>>>> choice arguments, I'd like to know whether they just generate
>>>> compiler warnings or fail to compile. Thanks in advance.
>>>
>>> I've done derived types with ifort 9 and MPICH 2 (although I
>>> subsequently switched to LAM and OpenMPI), but that was via mpif.h
>>> and not the module. MPICH 1 is problematic due to the lack of some
>>> of the MPI 2 inquiry functions.
>>
>> Just out of interest, what are the pros (& cons) of OpenMPI vs. MPICH-2?
>
> The issue I had with MPICH-2 was stability: sometimes it would refuse to
> start a job (for no reason that I could figure out), and sometimes in
> the middle of a job, it would crash out with a cryptic message about
> losing one of the daemons (which would be supremely annoying if it were
> to happen 3/4 of the way through a week-long job).
>
> In contrast, LAM and subsequently OpenMPI have been exemplary. An
> additional benefit with OpenMPI is that it has good integration with Sun
> Grid Engine, which is what we use to manage jobs on our group's cluster
> and is also what the university uses on its campus-wide high-performance
> computing resources. LAM has some issues with process cleanup, where if
> you're not careful you get zombie jobs hanging out on the nodes.
>
> I haven't attempted to benchmark relative performance.

My initial tests with MPICH-2 on my quad-core PC (Windows XP) produce
variable numbers of socket shutdown errors at MPI_FINALIZE(), i.e. not
while serious work is being done. This may be a warning flag.
Unfortunately OpenMPI is not yet available on Windows. No big deal,
since the PC will be just for code development. I don't know what is
used on our IBM cluster (Suse Linux), but it seems stable so far.
First  |  Prev  | 
Pages: 1 2
Prev: Any libraries for vector mask and vector population count?
Next: Preventing file sharing