[mpich-discuss] Predefined datatype implementation

[Jed Brown]

Jeff Hammond <jeff.science at gmail.com> writes:

>>> FWIW, even if MPI_VERSION and MPI_SUBVERSION are set correctly,
>>> there’s no guarantee that these types are available.  Types are only
>>> defined based on what compiler you use.  For example, if you use a C89
>>> only compiler, these types will not be available.
>
> Wouldn't the C89-compiled MPICH need to support these datatypes to
> provide interoperability with C99 code in exactly the same manner as
> it provides Fortran and C++ types for interoperability with code
> written in those languages?  It is ambiguous in what context the word
> "use" is used here so maybe I am misinterpreting your statement.

In that case, you should configure MPICH with C99 support (or at least
do not use -std=c89).

> Filesystem performance is a red herring.  Don't compile on the
> gold-plated filesystem.  Use /tmp or /scratch, as suggested by
> https://www.alcf.anl.gov/user-guides/compiling-and-linking-faq.  Every
> Linux login node has /tmp.

1. System headers and libraries are still often on a remote filesystem.
The workflow is a lot more complicated if you mirror that locally.

2. /tmp isn't shared between login nodes, let alone compute nodes, so
you have to copy back to global storage.  With multiple login nodes,
when you background/nohup a compilation task and log out or are
disconnected, you have to remember the login node number to get back to
the result.  The cognitive load of doing all compilation on /tmp,
especially with multiple packages, is not trivial.

3. Try teaching this to a novice.  The fact is that if HPC is going to
grow its user base, it has to be easier to use.  If you want to take the
elitist stance that expensive machines should only be used by experts,
stop giving INCITE awards to people that don't know how to use
compilers, debuggers, or the shell.  Until then, hiccups along the way
land in our lap, and a complicated workflow only serves to intimidate
and to create more opportunity for human error, which again comes back
in the form of support mail.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: <http://lists.mpich.org/pipermail/discuss/attachments/20131120/792405f6/attachment.sig>