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

[Pavan Balaji]

I think Nicolas' answer was perfect.  We couldn't have said it any 
better.  For most correct MPI applications, no changes should be 
required.  But very often, applications are less correct than you might 
think :-).  In any case, as far as we can, we'll try to work with you to 
help you move from MPICH 1.2.7p1 to MPICH2.

  -- Pavan

On 12/02/2011 05:16 AM, Nicolas Rosner wrote:
> 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
> _______________________________________________
> mpich-discuss mailing list     mpich-discuss at mcs.anl.gov
> To manage subscription options or unsubscribe:
> https://lists.mcs.anl.gov/mailman/listinfo/mpich-discuss

-- 
Pavan Balaji
http://www.mcs.anl.gov/~balaji