19 Feb
2018
19 Feb
'18
9:01 p.m.
On Sat, Feb 17, 2018 at 8:01 PM, Larry McVoy <lm(a)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.
ᐧ