[mpich-discuss] mpich 2 compatibility with mpich 1.2.7p1

[Nicolas Rosner]

Hi Akshar,

> can the code written keeping mpich1.2.p1 in picture be compiled with mpich2

Generally speaking, yes.

I'm sure there are exceptions -- for starters, even at the language
level your mileage may vary since e.g. plain C/C++ code (with no MPI
calls at all) that builds fine on a 2005 system/compiler combo may
need some tweaking before it will build just as fine on a 2011
system/compiler.

At the *standard* MPI level, most constructs that were legal syntax
back should still be, and even the few deprecated ones (try a search
for "deprecated" within mpi-forum.org) will work for a while before
actually breaking your build. Unless your legacy code depends on some
syntax quirk that was broken in MPICH and has been fixed since then,
you should be fine.

Beyond the standard, the question would be whether any MPICH-specific
extensions that you may depend on no longer exist in MPICH2. I have no
idea, but the experts on this list do, and can point you in the right
direction if need be. (Sounds unlikely without a good reason and/or
replacement.)


> will there be any change?

In behavior? There is no general answer to this -- could be a few
simple adjustments or a month-long nightmare. Predicting semantics is
tricky even while looking at code -- let alone with no clue on what
yours does/needs/assumes.

By "needs" I mean e.g. that code using dozens of different MPI
functions will usually yield more surprises than code based on just a
few. Of course quantity isn't but a rough estimator here; code based
on many functions but with simple semantics (e.g. Ssend, Recv,
Barrier) should be hardly as likely to surprise you as equivalent
approaches based on fewer yet more complex funcs (e.g. Bsend, Irecv,
Iprobe), which are harder to get right both on the user and the
implementor's side.

The "assumes" part is key, I think. How many lines of the legacy code
wrongly assume what they shouldn't could make the difference between a
straightforward and a grueling task, esp. when the leap is from a
half-decade old to a much more reliable and newer MPI implementation.
One tends to blame the latter (since it looks like the one variable
that has changed), but more often than not this boils down to
realizing it's just improved while one's own code was broken all
along. : )

Hope this helps, and good luck!

Nicolás