The Next Chapter for the Intel® Fortran Compiler 2023

[Ron_Green]

The Intel Fortran Compiler development team is thrilled to share news of our achievement in reaching a major milestone for the Intel® Fortran Compiler, IFX:  With the 2023.0.0 release, IFX now has Fortran language feature parity with our Intel® Fortran Compiler Classic, IFORT.  And this is no small feat. For the first time, IFX has full Fortran 2018 language support, putting it on par with IFORT.  This includes all the legacy DEC/Compaq/Intel language features, extensions, and all our compiler directives that you have come to expect in Intel Fortran!  But there’s more to the IFX story to celebrate! In a parallel effort, our Fortran compiler added OpenMP GPU offload features to enable your applications to access acceleration on Intel GPUs, such as the Intel® Data Center GPU Max Series. 

I have posted this blog article that details the evolution of IFX, features in IFX 2023, and where we are going with IFX and IFORT in 2023 and years beyond. 

I will open this thread for comments.  We know IFX is not quite ready to replace Ifort, at least for some users, with the 2023.0.0 version.  While the major development work is complete, we still need to stabilize the code.  But it should be quite close and should have reasonably good performance relative to ifort.  Make sure to use -xhost, -x<arch>, or -Ofast -flto, as one or the other of these options are needed to get Intel optimizations over and above baseline LLVM optimizations.   We have our Ifort to IFX Porting Guide to help with the differences between IFX and Ifort.  

We look forward to feedback on your experience with IFX 2023.0

ron

Keep up with all the latest from the Intel Fortran team by following me on Twitter @iCompilersRon
Ron Green #IAmIntel

[andrew_4619]

As a user who has yet to look at IFX, this post (and links) answers the many on IFX adoption.  Thanks.

[Steve_Lionel]

Very happy to see this - I have been selecting ifx for stuff I have been building, and haven't seen problems.

Ron, please pass on the suggestion to the Visual Studio integration team to add a Tools > Options feature to allow making IFX be the default for new projects, rather than having to individually select it.

[Ron_Green]

@Steve_Lionel We did discuss when the right time was for the VS IDE switchover to IFX.  2023 seemed too soon.  The majority of the team is thinking the right time is for the 2024 release.   However, I am also wondering if Update 1 or Update 2 might be good candidates.  I'll bring this up again with the architecture team.

[Steve_Lionel]

Hi Ron. I'm not suggesting that a switchover be made now, but that an option be added to allow the user to select which compiler to use as the default in new projects. This could go under Tools > Options > Intel Compilers and Libraries > General. This would default to IFORT for now, but a user could change it to IFX if they wanted to.

[FortranUser22]

I have an older license of intel Fortran compiler. Is intel Fortran compiler free now?  (as part of the intel OneAPI HPC Toolkit) . According to Wikipedia, it is free now with optional priority support: Intel Fortran Compiler - Wikipedia 

[Steve_Lionel]

That is correct - free with optional support.

[AnaWilliam850]

Thank you

[JohnNichols]

I have just spent 2 weeks updating several computers at the Smithsonian Institution that has a cell modem that after 10 GB runs at 75KB/sec.  It took three days to update VS 2022. The modem is faster at night when the traffic slows down and so you have to get up every hour to remove the error code that one had nine try's and it has stopped.    1.65 GB since 2 am this morning.  

Please bring back the MS 3.03 Fortran that fits on a single 5.25 inch floppy drive.  

[andrew_4619]

Actually did you mean 3.03 Fortran? I think 3.0 was for CP/M machines only, not IBM PC (8086). 3.31 supported 8086/8087 and came on 5 x 5.25 discs + a manual! 

[JohnNichols]

You are correct, for some reason I always think of it as 3.03, faulty memory chip.  I remember when I could afford a 20 MB hard drive and I did not need to swap floppy drives.  Those where the days.  I had hair an added bonus.  

I can buy it for 295 USD.  

[van_der_merwe__ben]

Over the last weeks I have been experimenting with getting our solution to compile using IFX rather than IFORT (under Visual Studio 2022 version 17.4.4 and IFX version 2023.0.0). The project has well over six thousand (yes 6000) .FOR and .F90 files in it. I am happy to say that I managed to get it to compile and link successfully. While I have not done any serious validation testing on the final application, I did run one model and it solved successfully.

The support of existing compiler directives and $DEC statement made the transition much easier.

Issues encountered (most reported via tickets) included:

• One file had code after a return statement which IFORT ignores but IFX does not, causing genuine unresolved externals.
• One file called an obscure Windows API function which seems to have disappeared, but it is not needed.
• Two files had functions wrongly declared as imported rather than exported, leading to unresolved externals. IFORT fixes this but IFX does not.
• About six files generate internal IFX errors when compiled using the array bounds check option. These files do not need that option.
• Two files ran into internal compiler errors due to arguments being declared as reference which they are by default anyways.
• Two files that interoperate with C/C++ using mixed string length arguments and bounds checking gave internal compiler errors, but I was able to rewrite the functions using the nicer ISO C binding options so they work with both IFORT and IFX.
• The stand alone Fortran installer component is missing some LLVM pieces, can be fixed by installing the C++ stand alone component as well, or installing the base and full api kits.

But given the sheer number of files, the list of issues was relatively small. With any compiler upgrade or change, we usually find some issues to clean up.

So well done Intel IFX team!

We shall likely not formally switch for some time, as it requires a lot more testing and validation and we shall likely wait for the next version of the IFX compiler. But this puts us in a better position for the future.

[Barbara_P_Intel]

Thank you for your comments! I shared them with the Fortran team; they ask that you continue to report issues to help all developers migrate to ifx.

[abhimodak]

Can you point to where one can find more examples related to OpenMP offload? 

One specific question (and perhaps answered somewhere else) is: can it do function offloading? For example,

Subroutine Work(J, K)

Integer :: J, K

K = 2*J

End 

Program Main

Integer :: J(100), K(100)

Integer :: n

do n =1, 100

     Call Work(J(n), K(n))

end do

End

And we want the do loop to run over the GPU. Canthis be done using OpenMP offload? (Potentially, there is cascade of 'calls' from Work.)

Abhi

[Barbara_P_Intel]

Yes, you can call subroutines from a loop within a TARGET region. Some extra OpenMP directives are required to let the compiler know.

The OpenMP website posts documents with examples. Here's a link. 

That same website lists books that are available. I have this one on my desk, Using OpenMP – The Next Step – by Ruud van der Pas, Eric Stotzer and Christian Terboven (2017).

[abhimodak]

Thanks Barbara! 

This is embarrassing but I will ask ... I am looking at OpenMP API 5.2.1 Examples – November 2022; chapter 6. 

I am wondering if it means (for the dummy example above), the following --

Program Main

Integer :: J(100), K(100)

Integer :: n

!$omp target

!$omp parallel do

do n =1, 100

     Call Work(J(n), K(n))

end do

!$omp

!$omp end target

End

I would imagine that there could/would be additional mapping clauses etc as needed along with certain restrictions as documented in chapter 6 of the book.

Abhijit

[Barbara_P_Intel]

I like to use mapping clauses to at least make the code self-documenting, same with shared and private clauses. There are defaults, but it's easier for me to understand the code and not try to remember the defaults.

To offload the subroutine, I believe you need a DECLARE TARGET directive.

More references for you.

Webinar: Three Quick, Practical Examples of OpenMP Offload to GPUs There are links to other webinars there, too, that you may find useful.

For when you're ready to optimize, check this out: oneAPI GPU Optimization Guide

[Barbara_P_Intel]

I just learned about this guide to OpenMP* Offload Basics in DevCloud  (with lab!).

[davidwarner]

Can you point to where one can find more examples related to OpenMP offload? 

One specific question (and perhaps answered somewhere else) is: can it do function offloading? For example,

Subroutine Work(J, K)

Integer :: J, K

K = 2*J

End 

Program Main

Integer :: J(100), K(100)

Integer :: n

do n =1, 100

     Call Work(J(n), K(n))

end do

End

And we want the do loop to run over the GPU. Canthis be done using OpenMP offload? (Potentially, there is cascade of 'calls' from Work.)

Abhi

[Barbara_P_Intel]

Yes, you can call subroutines from a loop within a TARGET region. Some extra OpenMP directives are required to let the compiler know.

Check the OpenMPI Examples, page 218. 

[Barbara_P_Intel]

Check out this new article written by Intel folks, Solving Heterogeneous Programming Challenges with Fortran and OpenMP*. It includes examples and explanations for using OpenMP TARGET directives to offload compute kernels to Intel GPUs.