On Sat, Feb 17, 2018 at 8:01 PM, Larry McVoy <lm@mcvoy.com> wrote:

I really don't see why. I can see why if they are using every library
known to man, but if you want portable you don't do that.

The ISV's customers are interesting in getting a specific job done - be it a simulation,

geo or therma prediction. Time to money is what matters to the end user - so they pick the 'best' product to do their job. Hence, e

xecution speed is typically the prime directive for an ISV like this and they are using Fortran for portability. Which is different from your design point I suspect. You need to be fast enough, but the choice of bitkeeper vs cvs vs ... is likely made with a different high order bit.

For the ISV, at a

minimum, it is a testing issue of the different perminations. They need to be fast, but their production code is deployed a top of 'a stack of turtles.' As I said RH Linux != SuSE != Ubuntu (they are similar but the kernels are not the same and the system DB's vary -- those tend to cause installation issues). GFortran != Intel ifort != PCG FTN != Cray FTN != IBM fortran. Much less GCC != Clang != Intel icc != IBM CC - cause interesting issues with dynamic loading. IBM MPI != HP MPI != OpenMPI != Intel MPI etc..tend to cause ISV code to step on each other.

Then you add Mellanox IB is not IBM is not Intel and ....

Mellanox Verbs is not Cisco Verbs is not PSM is not OFED

and locking and scaling starts to get strange

Each of these can be a 'little different' even though they all follow standards. It becomes a old Al Haig - style - "I'm in charge" problem. Moreover, I know of one large distro insists on only testing their IB stack point to point with two system, even when they have been offered a HW from a

vendor

that has 4 compute nodes plus a head node, just to chase and tease out the corner cases that drive the ISV mad.