Want tips on Porting Fortran developed on Intel WIndows IDE to Gfortran on Linux

[Anthony_Richards]

I have a straightforward 64-bit Windows console program .EXE that reads input from formatted files, crunches numbers and outputs to other formatted files. It consists of two  .F90 free-format files, one is a Fortran Module and the other contains the main program + subprogram code.
My standard of Fortran familiarity is F95. A requirement to speed it up can be met locally by porting the code to a much faster server which uses Linux and which has GFortran installed (but not Intel Linux composer - yet!).

The code uses no special directives or special functions, but it does invoke the  IFWIN module directly (for DOUBLE and DWORD) but no other special libraries or modules (AFAIK) so I hope it should port easily. I know that will have to change file names to match the Linux file naming and directory syntax, otherwise should this code therefore compile + link straightforwardly in GFortran to create a Linux executable?

Is it likely that the GFortran code will not be significantly slower than the optimised Intel Fortran-generated windows code so hopefully not compromising the hoped for increase in speed offered by the faster Linux-machine's multi-core processor?

Thanks in advance for advice on any tips re: porting to Linux.

[jimdempseyatthecove]

I suggest that you replace "IFWIN" with "myIFWIN" or some such named module, then insert what you need into your own module named myIFWIN. Initially this may be just the definition of DOUBLE and DWORD.

Caution, anything using DWORD is likely a call to a Windows library support function/subroutine.
Also, older applications used DWORD in lieu of HANDLE and this gets you in trouble when porting from 32-bit to 64-bit.

Specifying file names may be an issue with regard to / verses \ as well as Linux not using C:, D:, ...

If you are porting formatted data files between the Windows system and the Linux system you may have a minor, but solvable, issue with line termination (CRLF verses LF).

GFortran optimization is quite good. I wouldn't worry about this at this time. The server likely has more threads available than your current system, therefor it may be better to look at threading opportunities first, then consider the vectorization impact.

If you have time available, you could install GFortran on your current system, perform the "myIFWIN" module creation there. Then run a test between a fully optimized IVF against the GFortran. This will give you some idea of what to expect on the server for relative performance difference between IVF and GFortran (one system may have FMA and/or wider vector support). On of the principal reasons to use IVF is the excellent support (rapid response time).

Jim Dempsey

[Steven_L_Intel1]

You can probably replace uses of DOUBLE and DWORD with C_DOUBLE and C_INT32_T from intrinsic module ISO_C_BINDING. You could even write an "IFWIN" module that simply imports and renames those.

If the code is indeed straight Fortran and doesn't call Windows-specific routines, you'll probably be ok. But of course you should switch to Intel Fortran as soon as you can!

[mecej4]

The server may be faster, but you get only a slice of the processing time if the Linux system is taking log-ins from multiple users.

If the server is "faster" because it has more cores or more processors than you current system, you will need to parallelise your code. If you do not wish to go to the trouble of parallelising the code, you should compare the single thread performance of your current system with that of the server.

[Anthony_Richards]

Thank you all for your helpful advice.

[FortranFan]

Have you tried compiling your current code with /stand compiler option in Intel Fortran?  That can reveal a lot of non-standard elements in the code that may not port to gfortran.

My suggested steps are as follows:

• create a minimal working example (MWE) of code, something that has the same program setup and a much simpler, but reflective, data structure, and similar but much simpler I/O steps.  By simpler, I mean if the actual code gazillion arrays of various attributes (fixed size, allocatable, etc.), one only needs to process a model array; MWE doesn't need to do actual number crunching of course, it can simply assign a reflective output array to some value, and so forth..
• use /warn:all and /stand and turn on relevant (or all) run-time checks
• replace as much mixed language programming aspects with standard C interoperability features as possible
• get MWE to first work as console app (not QuickWin) in Intel Fortran on Windows with no errors; warnings should be limited to OS specific aspects, if relevant (such as Window API calls)
• get MWE to then work with gfortran on Windows
• then get the MWE to work with gfortran on Linux; one should need to replace just Windows OS specific stuff, if present.
• take the learnings and apply to actual code

[TimP]

As suggested above, ifort -stand will flag many extensions which gfortran won't accept. In many situations, gfortran needs -O3 -ffast-math -unroll-loops --param max-unroll-times=4 and appropriate -march= setting to rival ifort performance. Default gfortran on enterprise Linux may be outdated.