The computational load of these simulations is, in modern terms, not large, so Emscripten-compiled simulations would be plenty fast enough, and deployment of web pages in a computer-lab environment (or for people working from their dorms!) is way easier than the alternatives.
So there are real, non-trivial applications. You wouldn't want to be running ABINIT or whatever in your web browser, but GROMACS on some small system? Not unreasonable.
a) writing yourself an engine and that's actual work
b) that engine not being one which is used in real research
So "it depends" – for introductory teaching yes, for training researchers less so.
In a past job we had some ada code in our codebase that was just awful looking. It was machine translated from fortran to ada. From what I could tell, it was just a few files that were translated and then fixed up and checked in before they gave up on that conversion project.
we nicknamed such code "ada-tran"
Thus the I feel the new translated code should be called "Forscript"
> we nicknamed such code "ada-tran"
So the backstory is that Nvidia bought PGI, a company which produced a C/C++/Fortran compiler suite which was moderately commonly used in HPC. Then they took the Fortran frontend from the PGI suite and bolted it to LLVM and open sourced it as flang.
For example, it would be incredibly useful if you can run various US EPA's dispersion models right in your browser.
Core numpy depends on BLAS, for which both Fortran and non-Fortran implementations are available.
% ldd /usr/lib/python3/dist-packages/numpy/linalg/lapack_lite.cpython-35m-x86_64-linux-gnu.so|grep -E 'lapack|fortran'
liblapack.so.3 => /usr/lib/liblapack.so.3 (0x00007fb619ce7000)
libgfortran.so.3 => /usr/lib/x86_64-linux-gnu/libgfortran.so.3 (0x00007f5ae0911000)
Or rather, before flang + emscripten/wasm/whatever, there was no reasonable way to run Fortran in a browser; now there is. Application developers can then choose whatever is most important for their application.
Seems like most numeric/math code have some Fortran libraries underneath.
It'd be handy to have a route to just compile them to JS rather than having to write from scratch
Really, the 2nd coming of VRML.
Another example, I know the guy who maintains NIST's fluid properties solver (back in the day he worked at a subcontractor for NASA characterizing superfluids in fuel tanks). It's ancient Fortran compiled to a windows .dll and wrapped in VB in an excel file. It's super battle tested (being used for nearly 30 years), and it'd be awesome to be exposed in the browser.
Say we want to use BLAS and LAPACK in a C/C++ project that uses clang as the compiler. All we have to do is write the appropriate prototype for the LAPACK function in C and then link to BLAS/LAPACK. That said, there are four different name mangling schemes that the BLAS/LAPACK could use, which are combinations of upper case or with trailing underscores, e.g. gemm, GEMM, gemm_, and GEMM_. Both Autotools and CMake will determine the mangling scheme for us, but they need a Fortran compiler to determine that. Right now, that's almost always GFortran. With this project, it could ostensibly be Flang, which would eliminate the need for GCC to determine the mangling if a pure LLVM toolchain is desired.
The C ABI is pretty stable, so if you're using LAPACKE you shouldn't need to worry about which Fortran compiler was used to compile LAPACK.
Other than that, AFAIK the most common name mangling these days is lowercasing + trailing underscore. That being said, for "modern Fortran" with modules, OOP etc. the issues are vastly more complex and AFAICS there is no commonly agreed upon ABI.
EDIT: Confirmed - https://developer.arm.com/-/media/developer/developers/hpc/f...
So, if you want to do down-to-the-metal optimisation for Fortran, you want to write a Fortran compiler, not a Fortran program.
If you're not interested in science, I guess you could contribute to GCC or LLVM and try to make Fortran benchmarks run faster.
This is possible because you don't have to deal with all the weird edge cases you have in C/C++ like aliasing. The language is fairly simple so it can be optimized to death and it's easy to add things like automatic vectorization, etc.
You mean Coarray Fortran, which can be a substitute for OpenMP, but simpler.
This is a NVIDIA project.
The name re-use was a bit confusing.
The real appeal for using Fortran is that for beginners it's a much easier language to pick up than C (much less footguns, for one), and that working with (dense) multidimensional arrays is very nice, roughly on par with high-level languages like numpy, R, or MATLAB.
Just an example: How do you specify a fast readonly array in C? If I recall correctly it's
restrict const * const int my_array[n]
integer(4), intent(in) :: my_array(n)
Not even starting with array ops, multidimensionals, array slicing etc., that's already a big win in readability. Having a pass-by-reference language by default is refreshing for HPC purposes.
That being said there are disadvantages compared to C. Biggest one IMO is the lack of inline declarations, which especially makes privatizing things in OpenMP and OpenACC code a bit more tricky, i.e. it needs to be explicit.
Generally in the function declaration rather than the variable declaration, but to declare a non-aliasing pointer to array of constant ints would be
const int (restrict *my_array)[N];
int const (*restrict my_array)[N];
It is of cause possible to do that in C as well, but it is not as natural. You can use pointer structures in modern Fortrans as well (as in F90 and later). Again, the difference is that idiomatic Fortran often lead to faster code.
One real difference is that Fortran do not allow aliased memory in arrays unless that is specifically declared using the "equivalence" statement, while in C and C++ that is the default assumption. This allows for some optimizations that can't be done safely in C. In C99 and later, you can use the "restrict" keyword to state the opposite, namely that an array is not aliased, but usually you won't do that outside of tight loops if at all.
Edit: It looks like Clang 3.8.0 supports OpenMP, so this should be doable.
I used to work in a government research lab. We mostly used GFortran instead of Intel for political stability reasons. Your budget can change drastically from year-to-year (even if there's no change at the congressional level) because every dollar has to go through the entire bureaucracy before it makes it to your cubicle. The budget wars are constant at every level in the org pyramid.
GFortran is free, and always will be. Whether we can pony up for Intel is completely unknown 5 or 50 years from now. And a lot of people in the Fortran world are ultimately funded by Uncle Sam.
I know quite a few Fortran programmers, most of whom will avoid Gfortran because it lacks the features and performance of the commercial alternatives. When you consider that a lot of these people write code for large scale computer clusters and/or supercomputers, the cost of something like Intel Fortran pales in comparison to the cost of the hardware. I suspect this is a big part of why Gfortran is not of the same caliber as GCC