- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
As a user who has yet to look at IFX, this post (and links) answers the many on IFX adoption. Thanks.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
@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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
That is correct - free with optional support.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thank you
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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!
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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).
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I just learned about this guide to OpenMP* Offload Basics in DevCloud (with lab!).
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
![](/skins/images/45C6C2D737ED71F4C51F0145C8CB1E9C/responsive_peak/images/icon_anonymous_message.png)
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page