This is largely a quasi-religious issue, and the side you take on it is pretty much a function of how strongly you feel about the relative importance of certain factors -- all of the possible alternatives share these characteristics, but to differing degrees, and how the particular mix represented by each matches the combination of your own personal expertise and the requirements of the application you're currently working on, largely determines which particular approach you'll end up using. Even so, there are fairly broad agreements across the battlelines as to objective characterizations ... where things tend to break down is when "significance" and "desirability" get pulled into discussions.

1. Explicit message passing is the most flexible, portable, and tedious

   Message-passing is roughly analogous to building your own house from scratch: you get to do it just exactly the way you want it, and you don't have to put up with anyone else's preconceived notions of what's best. Some people like to focus on the "...exactly the way you want it ...", and some people like to focus on the "... you get to do it ...". There's no question that, if you're willing to do the work, you'll get the most tuned application-support from the message-passing approach.

2. Most data parallel programs do message passing "under the covers" on multicomputers

   As convenient as the data-parallel approach is to the person writing the code for the end-use application, it is nevertheless the case that, hidden down deep in the code for the library calls you'll find message-passing being implemented.

   The real question is, does it suit your needs? If it does, then you have a major portion of your work already done for you. But if it doesn't, then you'll likely have to start learning how to use the same message-passing send/receive mechanisms that were made use of by the data-parallel library.

3. Data parallel programs tend to be more concise and structurally similar to sequential codes

   This largely follows from the fact that all of the significant data movement that makes up the parallel aspect is taken care of virtually transparently, and, with that functionality hidden away, the code that is left has much more than a passing resemblence to sequential, single-processor codes doing similar tasks. This tendency is essentially the result of the fact that ...

   • data-parallel codes work best when they can follow the "natural parallelism" expressed in an algorithm, and
   • this is usually found in loops over some dimension or other for a given data object, and
   • this is one of the easiest ways for data to be split among available processors.