Last build for ifort and plans for removing ifort from packages in the later months of 2024

[Ron_Green]

Below is the opening paragraph for this blog post I wrote with details about the forthcoming removal of ifort from our packages and the last build for ifort.  There are too many details to summarize.  I suggest reading the blog post if you are currently using ifort as your fortran compiler.   Comments are blocked for that post but feel free to ask questions or comment on this Forum post. 

This Is The Last Planned Version of The Intel® Fortran Compiler Classic (ifort), as The Intel® Fortran Compiler (ifx) Becomes our Primary Compiler

In the second half of 2023 Intel announced the Deprecation and Removal for the Intel® Fortran Compiler Classic, (ifort).  The deprecation and removal notice appeared in the Intel® Fortran Compiler Release Notes,  in the product launch announcement, in meetings with our customers, in various blogs and webinars, and on our User Community Forum.  We hope you received the notice.  While you can still download ifort today ( Summer 2024 ), the time is soon approaching when there will be no more access to ifort downloads.  Also, the work that went into ifort 2021.13.0 that was released with Intel® oneAPI version 2024.2.0 in late June 2024 marked the last snapshot in the development of ifort that is planned for public release.  But be assured that our support for Intel® Fortran and support for Fortran in general is as strong as ever as we make the transition to our new compiler.  At this time, all users are asked to migrate from ifort to the Intel® Fortran Compiler, (ifx).  Here are some more details to help answer your questions and concerns.

[J_Kuthe]

David,

thanks for the reply.

The new benchmarks (2024, https://polyhedron.com/fortran/performance-ifx-vs-ifort/ ) were NOT run in parallel. Autoparallelization (/Qparallel) isn't available with IFX.

With the old benchmarks (2019) autoparallelization was used with Absoft and Intel compilers (in the benchmarks table column headers you see (AP) added). When one compares with those runs without autoparallelization, you rarely see an advantage, sometimes it gets worse (same findings as yours).

Both webpages cite the compile commands being used. According to these, OpenMP was disabled.

So to me, the conclusions from what I read on this page are:
IFX shows performance disadvantages vs. IFORT with respect to

• COMPLEX calculations 
• Parallelization (i.e. OpenMP usage)

For single-threaded programs that don't use COMPLEX, the performance is varying. Sometimes IFX does better, sometimes IFORT.

[Scott_Boyce]

Except all my chemical engineering courses were taught using both Imperial and Metric, and often using a mixture units on the same exam questions. I asked them why they did this, their response, you will not find a single factory in the United States that is not a mixture of both, so you have to learn both and know how to mix them correctly, otherwise you are an idiot-idealist for thinking the US will be entirely metric with the next century. Even with my post-grad, and career we do our simulations in metric but results are presented a variety of locally used units (like acre-ft for volume rather than km^3, which would get you laughed out of the room).

[Ron_Green]

2025.0 installers:  yes, they do not touch existing installations.  So your ifort installations are safe.

IFORT-only installer:  Unfortunately, no.  While it sounds like a simple request, the installer team and developers are not part of the compiler team.  

[JohnNichols]

In NSW recently, my old cousin, she is 91 and remembers Hitler marching into Austria, took me to her favourite watering hole, the publican said on being asked for a Tooth's old, sorry mate it is a Toohey's pub.  My opinion of Toohey's  old matches David's thoughts on IFX, but one cannot take an 91 year old Lady to a Tooth's pub in Newcastle, just not done.  

https://en.wikipedia.org/wiki/Tooth_and_Co. 

So yes I understand, just one lives in the shadow of the old world. 

[joerg_kuthe]

Hi Ron,

in your "Porting Guide for Intel® Fortran Compiler" I read:

"Windows*
For Windows, both compilers default to dynamic linking in all cases. You cannot use static linking on Windows."

I have tried it. Under Windows (using VS2022 and IFX 2024.2.1) my programs seem to link statically when I have the option /libs:static set.

Compiling with Intel® Fortran Compiler 2024.2.1 [Intel(R) 64]...
ifx /nologo /O2 /module:"x64\Release\\" /object:"x64\Release\\" /libs:static /threads /c /Qstrict-overflow /Qlocation,link,"D:\Program Files\Microsoft Visual Studio\2022\Community\VC\Tools\MSVC\14.35.32215\bin\HostX64\x64" /Qm64 "D:\Temp\INTEGERoverflow\INTEGERoverflow.f90"
Linking...
Link /OUT:"x64\Release\INTEGERoverflow.exe" /INCREMENTAL:NO /NOLOGO /MANIFEST /MANIFESTFILE:"x64\Release\INTEGERoverflow.exe.intermediate.manifest" /MANIFESTUAC:"level='asInvoker' uiAccess='false'" /SUBSYSTEM:CONSOLE /IMPLIB:"D:\Temp\INTEGERoverflow\x64\Release\INTEGERoverflow.lib" -qnextgen -qm64 "x64\Release\INTEGERoverflow.obj"
Embedding manifest...
mt.exe /nologo /outputresource:"D:\Temp\INTEGERoverflow\x64\Release\INTEGERoverflow.exe;#1" /manifest "x64\Release\INTEGERoverflow.exe.intermediate.manifest"

INTEGERoverflow - 0 error(s), 0 warning(s)

Then the .exe is much bigger than the one created with option /libs:dll set.

Am I misunderstanding your statement?

Joerg Kuthe
QTsoftware.com

[andrew_4619]

As you observe you can static link on windows in IFORT but not if you have any parallel code which requires dynamic linkage.

[Ron_Green]

The statement in the Porting Guide is probably too restrictive.  As you have seen, there are cases where we do have static libs for core runtime functions.  I can revisit that text, thank you for pointing that out.

But as for determining the static vs dynamic status of your .exe - using file size is fast check.  But to be sure you truly do not have any dynamic dependencies OR to find your dynamic dependencies you should use other tools.  dumpbin.exe is one tool from Microsoft that is helpful.  Another tool which I use is "Dependency Walker", aka "depends.exe".  Both of these are described in a good post on Stack Overflow.

[Steve_Lionel]

On Windows, there are no static libraries for coarrays or OpenMP; otherwise static libraries still exist.

[Umar__Sait]

It would be nice if we can have an ifort only final package for those who will have to stick with ifort until ifx speedup issues improve with complex arithmetic. Furthermore, how about libraries like mkl? Will the new ones work well with ifort?

[Ron_Green]

ifx and ifort have the same API and both work with MKL.  Similarly, any 3rd party libraries that work with ifort 2021.x will work with ifx 2024.x and 2025.x.  

[jimdempseyatthecove]

I think if your broaden the scope of the section you quoted, you will find that it is referencing Intel Fortran supplied libraries such as those for OpenMP and MKL, ..., and not specifically for user written libraries.

Jim Dempsey

[DavidWhite]

Ron,

There are a number of posts now from serious developers saying that there is a significant performance hit with ifx.

I am yet to see any response from Intel saying that this is being addressed.

Are Fortan users and developers no longer a priority, particularly since OneAPI became free?

For Fortran, performance has always been key - when are Intel going to address this.

Thanks,

David White

[Devorah_H_Intel]

While oneAPI HPC and Base Toolkits are free to download, Priority Support is available for purchase for those who are interested.  

---

@DavidWhite wrote:

Are Fortan users and developers no longer a priority, particularly since OneAPI became free?

---

[Ron_Green]

David, we are addressing performance issues.  I do not know why you have the perception that Fortran users would not be a priority.  As manager of the Fortran development team I can tell you that Intel does still value Fortran and is supporting our development team.  The fact that oneAPI can be downloaded for free has had no effect on our team and our development efforts.

When we have an application that is showing a performance issue with ifx vs ifort AND if we are given access to the application we can do something about it.   And as a software developer, you know that not all issues are created equal: some can be fixed over a cup of coffee, others take months or years and major refactoring. 

We are improving each ifx update for functionality and performance, to the metric of roughly 200 fixes for each update, and 800 between major releases.   It is important for people to understand that pace of progress and the implication to stay up to date.  it is critical to keep compilers up to date as we mature ifx and address reported issues.  And it's also important to report issues along with reproducers - we can't fix that which we cannot test.  Reports should include the compiler version, options, and hardware on which it was run.

I hope this addresses your general concerns.  Is there a particular application of interest to you?

[Scott_Boyce]

I think it is awesome that you are doing that and I look forward to pivoting to ifx. Until ifx is a true replacement for ifort, both in speed and ability to compile code, ifort should continue to be available for download. Otherwise, people will just pivot to other up and coming compilers, or start translating code to other language. Our group is working on compiling a windows version of Flang to see how it compares, something we would have never considered until ifort was dropped.

[JohnNichols]

If you store away the installers for an old IFORT say 2024, which is not hard, and then install them and then update, one has the last IFORT and the current IFX.  I just did it on an old NUC3 and it runs nicely. 

Performance is an interesting issue, I have a program that is threaded, because of data collection the first thread takes exactly 8.192 seconds, the second thread does a lot of analysis on the last collected set and has 8.192 seconds to return to be ready for the next step.  So I carefully watch the FFT performance on the second thread. On a core 7 Intel it takes 2 seconds, on a core3 Nuc 6 it takes about 2.5 seconds.  FFT analysis has not changed in a noticeable fashion with IFX.  

[Scott_Boyce]

Yeah, I pulled the offline version of 2024 oneAPI so I can keep on hand ifort. I just worry about support of VisualStudio, which for a while did not work a few years ago, and if there are no patches for VS for ifort then it will be effectively dead. Also I just spent most of last week helping some outside developers that cloned my repo, installed oneAPI, then could not figure out why they could not compile the code (since it did not include ifort) nor do they have access to the 2024 ifort download.

[Devorah_H_Intel]

---

@Scott_Boyce wrote:

Yeah, I pulled the offline version of 2024 oneAPI so I can keep on hand ifort. I just worry about support of VisualStudio, which for a while did not work a few years ago, and if there are no patches for VS for ifort then it will be effectively dead. Also I just spent most of last week helping some outside developers that cloned my repo, installed oneAPI, then could not figure out why they could not compile the code (since it did not include ifort) nor do they have access to the 2024 ifort download.

---

Please make sure you report the issues with Intel Fortran Compiler (ifx) VS IDE issues to us. Do you have a priority support- this would expedite fixes. The new VS IDE integrations for ifx also work with previous ifort compiler versions already installed on the system. 

[vmarkel]

In the post reference below, I have provided an example of ifx not linking correctly.  In fact, I am not able to use ifx with any of my projects, which all work fine with ifort. What am I doing wrong? Would be very grateful for your help, especially since ifort is being phased out soon.

community.intel.com/t5/Intel-Fortran-Compiler/Error-linking-with-ifx/m-p/1637158#M173961

[J_Kuthe]

It's the IPO option which causes the problem as stated in the Porting Guide:

https://www.intel.com/content/www/us/en/developer/articles/guide/porting-guide-for-ifort-to-ifx.html

"... However, if you compile using the -ipo compiler option, there is no compatibility between the object files created by ifort and ifx. "

Joerg

[vmarkel]

Indeed, it is the -ipo option that's causing the problem. However, the Porting Guide is wrong. In fact, what happens is "if you compile using the -ipo compiler option, there is no compatibility between the object files created by ifx and ifx"