[mpich-discuss] Predefined datatype implementation

[Jed Brown]

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

> On Wed, Nov 20, 2013 at 2:20 PM, Jed Brown <jedbrown at mcs.anl.gov> wrote:
>> Jeff Hammond <jeff.science at gmail.com> writes:
>>
>>>> 1. System headers and libraries are still often on a remote filesystem.
>>>> The workflow is a lot more complicated if you mirror that locally.
>>>
>>> The workflow does not change at all.  E.g. "#include <stdio.h>" works
>>> irrespective of where you build.
>>
>> Yes, slowly because it's coming from the global file system.
>
> Sorry, but no, /usr, /opt or /soft are not mounted from a global file
> system.  The beauty of static linkage on this huge supercomputers is
> that the system headers and objects don't have to be visible to the
> compute nodes.  When they are, it is usually (e.g. Cray and IBM Blue
> Gene) via a special ramdisk or local mount that makes the access fast.

Depends on the system, but on ALCF systems /projects/ is GPFS.  That
includes /projects/llvm/, among many others.  That's what I get when I
load +mpiwrapper-bgclang.

>> 1. You have to remember an extra number (the login node number).
>
> Clearly, this is too great a burden for any computational scientist to bear.

Even experts make mistakes, and every extra thing slows down and
complicates the process.

> Novices don't build anything from source, just like novice drives
> don't chair their own oil or tires.  You're abusing the word novice in
> an attempt to make a weak argument if you contend otherwise.

Lots of people, from grad students to full professors at top-10 research
universities and senior scientists at national laboratories trip over
this stuff on a regular basis.  In this context, "novice" can mean
anyone without significant experience in compilation, linking, and HPC
systems.

>> Or we can agree that although requiring every package to test a zillion
>> things in their configure sucks for workflow, usability, and speed,
>> there is no viable technical solution available, so we have few options
>> short of the life-consuming task of attempting to build and distribute a
>> real solution.
>
> Your novice users should use the provided installations or request one
> if the package they need is not available.  If they want more than
> release versions of standard packages, they aren't novices and need to
> RTFM their way out of their problems.

I do not believe that ALCF or any similar facility has the manpower to
install all packages that novice (non-expert) users require.  Meanwhile,
many of those packages don't have quality release processes, and it's
not uncommon for upstream to have no experience on a particular
architecture.  And smaller university clusters have much less support
resources.  The fact is that a large fraction (likely the majority) of
computational science is performed by people that are not experts at the
practicalities of running on HPC systems.  Unless you intend to overhaul
the education system, this will continue to be the case and perhaps
escalate.  Overhauling education would be a laudable goal, but will take
a lot of effort and a lot of time to effect.  Meanwhile, we live in the
present.
-------------- 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/ef70211c/attachment.sig>