janemou janson lester

0 views

Skip to first unread message

Maybell Hughs

unread,

Aug 2, 2024, 7:47:17 PM8/2/24

to payficentfras

GFortran is the name of the GNU Fortran project. The main wiki page offers many helpful links about GFortran, as well as Fortran in general. In this guide, the installation process for GFortran on Windows, Linux, macOS and OpenBSD is presented in a beginner-friendly format based on the information from GFortranBinaries.

Windows Subsystem for Linux (WSL): An official compatibility layer for running Linux binary executables on Windows. With Windows Subsystem for Linux GUI one can run text editors and other graphical programs.

Finally, you can switch between different versions or set the default one with the update-alternatives (see manpage). There are many online tutorials on how to use this feature. A well structured one using as an example C and C++ can be found here, you can apply the same logic by replacing either gcc or g++ with gfortran.

OpenCoarrays is an open-source software project that produces an application binary interface (ABI) used by the GNU Compiler Collection (GCC) Fortran front-end to build executable programs that leverage the parallel programming features of Fortran 2018. Since OpenCoarrays is not a separate compiler, we include it here, under gfortran.

While with gfortran you can compile perfectly valid code using coarrays, the generated binaries will only run in a single image (image is a Fortran term for a parallel process), that is, in serial mode. OpenCoarrays allows running code in parallel on shared- and distributed-memory machines, similar to MPI:

There is also a separate distribution of mingw-w64 that can be installed without MSYS2, but I don't recommend it, as the last files there have gcc-8.1.0, from 2018 (apart from a recent build by Ray Linn that includes the Ada, but not the Fortran compiler).

Another compiler that is now free is Intel Fortran : you have to install Microsoft Visual Studio Community, Intel oneAPI Base Toolkit and Intel oneAPI HPC Toolkit. More information here. Available on Linux, macOS and Windows (of course, Visual Studio is needed only on Windows). Intel oneAPI is at least partly open source, not sure about the Fortran compiler.

MSYS2 is a much smaller package (in terms of disk pace needed), and is used by several other free projects: R (Rtools), Octave and Strawberry Perl all include parts of it, including the gcc compilers.

To compile Fortran code for Windows you need a Fortran compiler for Windows. Microsoft neither provides a built-in one nor offers one for sale. Third-party compilers are available, including gfortran, but you'll need to install one yourself. If you want to use gfortran in particular, or if you like it simply because you don't have to spend money to get it, then I would recommend obtaining it as part of mingw-w64. Alternatives are available from multiple vendors, some free of charge, but most for sale.

As a followup from this, in the short term what I need is to build a statically-linked binary of the latest version of my package. In linux it is just about installing gfortran and cmake, and doing make.

I have just spent one hour trying to install some fortran compiler on Windows, without success. I have no real experience with doing anything on Windows, so probably this is just my lack of knowledge.

I can recommend MSYS2, it gives you a bash shell with a Cygwin-like runtime as base and (several) MinGW native toolchains on top, which allows linking static binaries for distribution outside of MSYS2. From my experience this is the closest Unix experience one can get on Windows, while still being able to create native binaries. However, it might appear a bit complex due to the different available environments on the first glance.

After installation there will be several terminals available (msys2, mingw64, mingw32, ucrt64, clang64, clang32). The msys2 terminal is a pure Cywgin-like environment, software from this environment is available in all environments. mingw64, mingw32 and ucrt64 are based on GCC/MinGW, here you get gfortran as Fortran compiler. In clang64 and clang32 you can instead rely on flang as Fortran compiler.

On Windows, if you need as comprehensive a Linux tool experience as possible, and the latest packages (its gfortran will always keep the latest version), MSYS2 is very good, which I have been using.

I managed to document creating Windows executables on Linux by cross-compiling. My experience is detailed here. If you need access to Windows DLLs it becomes more complicated, but if you stick to straight Fortran, it is nice to have one shell script that compiles both executables. Now if I could only cross-compile to OSX.

The program reads problem data from the standard input stream, using Unit 5. This, by itself, is fine, but the program attempts to read the input twice, with a REWIND(5) in between. Depending on the operating system and the Fortran compiler being used, this may fail if the standard input is obtained by redirection from a file.

In various places, there are WRITE statements in which the output list contains references to the character function i5hex. However, the function i5hex itself contains WRITE statements to an internal file, and such recursive I/O statements may not work or may not work correctly.

If I was to read it once I would need at least to know the number of lines, to preallocate a vector of strings with proper size. Is there any way to do that? Or a push? At the same time that has not been an issue in the many years Packmol is out there.

The Fortran standard has a section on Internal Files. In Fortran 2018, for example, the section is 12.4. Recursive I/O can be avoided by using a temporary character variable which is set to the function value, and placing that temporary character variable in the I/O list. For example, instead of

Thing is, given the same code same optimization flags, intel fortran behaves the same for all the OS.
gfortran on windows is 6 times slower than on Ubuntu.
The time are just the running time. The compilation time is excluded.

One cannot say why gfortran is slower than Intel on Windows (and slower than gfortran on Linux) for an undisclosed code. Can you post the code or at least a fragment which demonstrates the speed differential?

Speaking of IO, in fact, it reminds me that, I do notice in windows the file system like NTFS is significantly slower than the linux file system.
It looks like the same NVME SSD can have much higher actual IOPS on linux than on windows.
I guess someone else may have the same experience on windows. That is, even if I use things like RamDisk to do some IO using ram, the speed is almost the same as I do the IO using my SSD.
Such as installing the same MikTex in RamDisk and in SSD, the installation time are almost the same, and I compiling latex files in RamDisk, and on SSD, the time is still the same. I was expecting that if I compile latex files in Ramdisk, the speed will be as fast as hell. But I was wrong, there is no performance gain than running latex on SSD.
The file system of windows is the limitation, not the hardware.

I like the idea is ramdisk actually .
I previous thought that if I install latex in ramdisk, and then compile latex files there, things will be lightning fast! But it turned out to be the speed of compiling latex on randisk is the same as compiling it on my ssd, lol. Because on ramdisk is file system is still NTFS.

I am developing a package in Fortran and I hope it can be used on Win/Linux/Mac. Letting the user installing gfortran and Make on windows is a very convenient choice. Otherwise user need install Intel OneAPI which is also great but does not really optimize for Apple M1.

So I think if gfortran works fine on Win/Linux/Mac, it can be great.
But the issue of gfortran I have met on windows is that its performance is several times slower than on Linux.
Also, gfortran/gcc seems still some compatibility issue with M1 chip. For example, if use a pointer to point to a function/subroutine, gfortran seems can only work with -Og flag. With more than that optimization it will cause some error on M1 chip.

@CRQuantum, I think that many of the statements and conclusions stated in the various posts in this thread are unfair to Gfortran. Not much has been said about which versions of Gfortran were used on Windows, and which emulation layer/DLL support infrastructure was used.

A brief scan of your sources made me suspect that it uses 8-byte integers in many places where 4-byte integers would have sufficed. This choice, naturally, affects performance, but I did not want to spend any time to alter this aspect of the code.

I took your Gitlab sources, and commented out most of the WRITE statements, until the program produced just 16 lines of output. Here are the run times on my NUC (small box PC with low power laptop processor i7-10710U, laptop memory, on a ramdisk, balanced power setting, Win11-64).

I strongly suspected that the difference in the Gfortran times is attributable to Cygwin using (naturally) Cygwin1.DLL rather than the MinGW DLLs. If so, most of the slowdown that you noticed is attributable not to the compiler but to the runtime (which is also used by GCC, G++, etc.). I ran a test to settle my suspicion. I used Cygwin Gfortran to produce .o files, and linked the .o files using the MinGW Gfortran. The resulting a.exe took 2.8 s. This proves that there can be drastic differences in run times of Fortran programs depending on which versions of the GCC RTL are used. We may note in this connection that MinGW was last updated in 2013, whereas Cygwin was updated just two months ago.

You may attempt to modify your code to reduce the number of calls to PYQ_I, or to make it a vector function instead of a scalar, if that is feasible. Secondly, as I mentioned earlier, see if you can be more judicious in using 8-byte integer variables.