While thinking this through, there are a number of serious issues with WCC I can spot. I won’t go through them here, I want to mull over them for a while.
MPI. Supporting a new interconnect is hard. You have to relink your application. This is true on *all* platforms. Some such as the Scali system attempt to make this easy by separating layers, and allowing you to compile your app and select the fabric at runtime. This is a great idea. Unfortunately it is not in as common use as I would like. Most of the major ISVs don’t support Scali (a few do), most do MPICH/LAM and others. LAM has some ability to do this as I remember, haven’t looked recently, but it is in maintenance mode with new work going on in OpenMPI. MVAPICH is garnering lots of attention these days due to its support of IB, multirail, RDMA, etc.
But thats the point. There are lots of them. What is an ISV supposed to write to? Moreover, some of these are (rapidly) moving targets. Moving targets are not good from a developer point of view. Adds cost, time, reduces quality as you have to spend more of your limited resources chasing it.
This is not a linux specific problem. Windows has the same issue. What Microsoft is basically promising (which would be good) is to unify this (on windows of course).
The unification would be a good thing. A nice DLL that let us use new features when ready without rebuilding the code would be wonderful. We could do this with Linux as well. The LD_PRELOAD mechanism is very helpful. We choose not to for some reason when we build statically linked binary MPI. There are arguments for this. I don’t remember them, but some people are staunch defenders of the status quo.
While this is good, there are some bad elements of this. Most of the development that I am aware of going on in new MPI and related technologies is going on outside the windows world. So these folks are largely going to miss out until Microsoft gives the green light. This is true in more than just MPI, advanced networking, filesystems, etc.
This places the Microsoft solution firmly behind the powercurve. Maybe thats where they want to be, but I would think a better strategy would be cross platform unification.?? This way they could take advantage of developments on linux.
Finally, a way to win hearts/minds is to make the barriers to adoption as low as possible (this is what Linux did, made them effectively non-existent). This way, code could easily ported from an existing Linux port w/o significant changes. I had previously suggested the Cygwin technology for this. I might suggest again that Microsoft buy that from Redhat, make it a first class environment for Windows, and have all our comfortable tools there. Lower those barriers.
Somehow, I don’t think this will happen, but it is worth at least suggesting it.?? You may view their effort as either a good thing or a bad thing.?? More choice is good for the market.?? Vendor lockin is bad.?? Ask any customer what they think of being tied to a single vendor.?? None that I am aware of like it, many are eschewing it.?? Which is why Linux is so popular here, no one company controlls it.?? You don’t like what you see, you can choose another supplier.???? Microsoft could do good things here, or they can do bad things here.