Intel® Fortran Compiler
Build applications that can scale for the future with optimized code designed for Intel® Xeon® and compatible processors.
28384 Discussions

The Next Chapter for the Intel® Fortran Compiler 2023

Ron_Green
Moderator
10,490 Views

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

31 Replies
andrew_4619
Honored Contributor II
8,645 Views

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

0 Kudos
Steve_Lionel
Honored Contributor III
8,640 Views

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
Moderator
8,611 Views

@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.

0 Kudos
Steve_Lionel
Honored Contributor III
8,609 Views

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.

0 Kudos
FortranUser22
Novice
8,294 Views

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 

 

 

0 Kudos
Steve_Lionel
Honored Contributor III
8,259 Views

That is correct - free with optional support.

AnaWilliam850
New Contributor I
7,762 Views

Thank you

0 Kudos
JohnNichols
Valued Contributor III
7,749 Views

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.  

 

0 Kudos
andrew_4619
Honored Contributor II
7,738 Views

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! 

0 Kudos
JohnNichols
Valued Contributor III
7,703 Views

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.  

0 Kudos
van_der_merwe__ben
New Contributor I
7,581 Views

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
Moderator
7,559 Views

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.

 

0 Kudos
abhimodak
New Contributor I
7,179 Views

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

0 Kudos
Barbara_P_Intel
Moderator
7,158 Views

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).

 

0 Kudos
abhimodak
New Contributor I
7,140 Views

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

0 Kudos
Barbara_P_Intel
Moderator
7,053 Views

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

0 Kudos
Barbara_P_Intel
Moderator
4,626 Views
0 Kudos
davidwarner
Beginner
5,575 Views

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

0 Kudos
Barbara_P_Intel
Moderator
5,449 Views

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. 

0 Kudos
Barbara_P_Intel
Moderator
5,143 Views

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.

 

Reply