On Sat, Feb 17, 2018 at 8:01 PM, Larry McVoy 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. ​ ᐧ -------------- next part -------------- An HTML attachment was scrubbed... URL: