I’m not sure if that holds. Every university I’ve ever done research in has no issues paying for software like MATLAB, ANSYS, Mathematica, Intel MKL, Intel Compiler Suite, and the like. The people I know that still use Fortran (including myself) are all heavily focused on computational numerics and the fact that ifortran is closed source vs gfortran being open just does not even factor into the equation. If it’s available to me, and I can show that a program compiled by ifortran and MKL is faster than one compiled by gfortran and BLAS then I will use the faster one.
I left that world a long time ago, but what held is there was no problem buying site licenses for big software, not as much "I'm a research assistant and I'd like to buy X for $Y,000 for my project" The difference being buying something with broad appeal used by lots of people within the university, and buying something that I'd like to try for my project. Especially when there's already an established method which doesn't involve spending your PI's grant money.
You must have done research at well funded universities :)
My experience is quite different. Although after some hassles I was able to get license but it’s online only.
Overall I’m trying to move away from commercial software (I don’t teach any, only use foss) but yeah Mathematica, MKL + ifort are unbeatable in some respects (Matlab is slowly going to be replaced except some specialised toolboxes, don’t use ansys)
Anyway, proprietary and closed source software is in my opinion harmful for academia. Sometimes a lot, sometimes a little but in general it’s no good, although I understand that it funds some development that wouldn’t be done otherwise.
Not sure how I could proprietary/closed software being 'harmful'. If the product is superior and allows researchers/students to do a better or more efficient job then why not (absent severe budget constraints)? It is highly unlikely that those end users would ever modify the code or even need to view the source.
The fact that universities splurge money on these proprietary tools rather than spending it on long-term improvements isn't a good thing, even without the pain of actually supporting them.
The typical differences between stuff using ifort/MKL and gfortran/OpenBLAS/BLIS are at least similar, and probably smaller, than the sorts of variation you see anyhow on HPC systems, even without the important large-scale optimizations.
The company is distinct from their various products. For instance, their POP services are gratis. The NAG library is proprietary but, when I last knew, probably the majority of it was based on code from Netlib etc.
Ho, ho. I've been told by a NAG representative that we should pay them to talk to our own academics who actually do the serious linear algebra! Also I was told they were contracted to do the old AMD proprietary BLAS, which was inferior to OpenBLAS, and has been dropped in favour of BLIS. I don't wish to slight the general quality of their stuff, though. Their Fortran compiler is notable in this context.
You don't get the large scale parallel libraries from NAG anyway.
> We all know what the quality of academic code reputation is.
do 'we'?
considering a huge amount of common numerical software (esp with any kind of fortran lineage whatsoever) is based in some way on netlib.org code that itself was heavily developed in the BSD UNIX on Vax+ARPANET era within the academic/research community, I'm not really sure that, based on this comment, 'we' do..
Writing your own crypto is a bad idea, but in research sometimes the goals of your research require you to become good enough, and by good enough, I mean a notable expert in the "writing your own crypto" equivalent. Which in this case would be something like writing your own linear algebra library functions for research you plan to publish.
Non-trivial experience in research computing support says that gfortran is surprisingly more reliable than ifort. "Just use GCC and openmpi" has worked in enough cases for me. A number of HPC benchmark lists I've seen have had failures in the proprietary lines and not GCC's.
The performance advantages are largely mythical too. The last time I ran the Polyhedron benchmarks with beta versions of ifort and gfortran on SKX with the best obvious overall optimization (profile-directed), the bottom line was insignificantly faster with gfortran. Gfortran is infinitely faster on ARM and POWER too.
I wish research councils would support the free software.
GCC has made large improvements in the last 10-15 years in fortran support and performance. Memory is long and sometimes you just learn things as a beginner which remain "true" regardless of the changing facts.
Intel Fortran was far superior in language support and binary performance in the mid 2000's and a researcher couldn't be without it.
Whatever the reason, people shouldn't be propagating the incorrect information, especially if they're in research, and if they're interested in performance, which requires measurements. The same thing needs saying over and over here and elsewhere.
I don't remember figures and dates, but g77's performance was at least reasonably competitive with proprietary Unix compilers once GCC's backend was sorted out for the architecture (scheduling in particular). It was also mostly more correct. Observationally, researchers could do without ifort, especially on non-x86 hardware -- although ifort morphed from the DEC^WCompaq compiler which was used on our Alphas. (A good deal of work was done for g77 specifically because of problems at the time with portability and availability of compilers for a high profile computational project.)
