topic Re: Last build for ifort and plans for removing ifort from packages in the later months of 2024 in Intel® Fortran Compiler

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

Ron_Green — Tue, 16 Jul 2024 21:39:08 GMT

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.

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

Steve_Lionel — Tue, 16 Jul 2024 22:57:14 GMT

When ifort is removed, what will the ifort command do? I had suggested earlier that it invoke ifx - otherwise, LOTS of build scripts and third-party integrations will fail, with a heavy load placed on Intel Support.

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

Ron_Green — Tue, 16 Jul 2024 23:09:44 GMT

There was a long discussion with the entire team in multiple meetings on whether or not to make a thin wrapper named 'ifort' to invoke ifx OR to 'fail hard' if one tries to invoke ifort. Here's the argument against a sym link or thin wrapper:

- ifx is NOT ifort in many ways.

- Pretending it is 'same' will undoubtably cause confusion when or if behavior or numeric differences occur

- it allows 'ifort' to persist long after it is no longer available and no longer supported

AND, of course

- users can create their own sym link or wrapper IF they want to pretend ifort == ifx and buy more time to migrate, but we do not want to encourage that

Believe me, there were heated arguments on both sides of the debate for and against thin wrapper or sym link. In the end, the decision was "to pull the bandage" now and be up front about the end of ifort. This is why I am out to alert as many people as possible that IF they want to continue to use ifort, download it NOW before it is removed from the package, OR purchase a Priority Support license so they can have download access for the normal 'current -2' support model.

it will be painful when ifort is removed, but it has to occur sometime.

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

Ron_Green — Tue, 16 Jul 2024 23:14:34 GMT

I should add - for the Windows Visual Studio users - simply do NOT remove your latest version with ifort. Keep it installed so that after version 2025.0 comes out you can change your project configuration to use the older version's ifort which will still be installed on your system.

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

Neels — Wed, 17 Jul 2024 10:46:11 GMT

Ifort will still exist a long time. I have to support 32bit software for at least the next 10 years, maybe longer. In an industrial environment computers often live with the machine for the rest of the machine's life without being upgraded.

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

jimdempseyatthecove — Wed, 17 Jul 2024 15:44:33 GMT

Many (not all) scripts use a defined environment/macro to specify the Fortran compiler. $(FC) is often used.

So the script issue may not be as bad as first thought.

Some of the affected users may have success in making a batch file, and handle issues with ifort.cfg (as well as IFORT specific environment variables).

Jim Dempsey

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

David_DiLaura1 — Wed, 17 Jul 2024 16:09:17 GMT

It will be a (long?) while before we are able to use ifx for our production releases. Our most recent comparisons still show a considerable difference is execution times, and our customers will not tolerate such a step backward in performance. We produce radiative transfer analysis code, typically used with very large models of buildings.

Code:

Very large arrays (real 4-byte floats, complex numbers are NOT used)

Large threaded loops (with extensive preludes to setup the threading)

Virtually no disk access

Performance

A modest project on a 20 (physical) core Dell calculates as follows:

IFORT: 707 sec

IFX: 930 sec.

The disparity grows as the project size gets larger.

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

Umar__Sait — Sat, 20 Jul 2024 12:16:39 GMT

I urge the Intel development than to speed up complex algebra to be as fast as ifort. We cannot swithc to ifx because most of our production codes used complex arithmetic heavily and the codes run about 30% slower on ifx. Some codes have to run for days so this means a lot of time. What is the urgency in removing ifort, why not just keep it and do only security updates etc.

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

Cameron — Mon, 22 Jul 2024 18:58:38 GMT

Can we get an updated post/sticky on best practices for migrating IFORT to IFX?

I used the below post as my starting reference; is this post still the best for other users to start with?

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

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

Ron_Green — Wed, 24 Jul 2024 16:12:24 GMT

Yes, that link is our page to capture notes to help with moving from ifort to ifx.

We capture common issues and key differences. It's a living document so if you or others find techniques or problems in the migration to ifx we would like to hear about it.

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

sindizzy — Sun, 28 Jul 2024 16:36:59 GMT

@Ron_Green I have the Intel® oneAPI version 2024.2.0 package installed and i dont show ifort 2021.13.0.

Instead, it shows ifort 2021.12.0.

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

Ron_Green — Mon, 29 Jul 2024 14:15:17 GMT

that is the correct compiler. In the IDE integration the version was not updated. The command line -what -V options will show the correct version. I will add a note to the article to explain the error in the VS IDE version info.

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

Andrew_Smith — Fri, 09 Aug 2024 10:31:51 GMT

When new installers arrive without IFORT, will they leave IFORT installed if we have it?

Can we have an IFORT only installer for the last version? This would make new installs simpler.

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

JohnNichols — Fri, 09 Aug 2024 14:12:58 GMT

The issue of IFX and IFORT is like all science, one day you have to become a metric person, unless you are _______________

Of course in Latin

A fronte praccipitium, a tergo lupi

Walking off the front is probably better unless you have a spear.

One can always just leave the old IFORT installed on a computer and leave the computer alone and just use it. That will work until the computer and windows no longer safely update, about 5 to 10 years. I have this problem with old NUC6 computers that will not take Windows 11

Who selected the # key on the key pad for the Intel LOGIN why not use the commonly used 1 as the banks do?

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

JohnNichols — Fri, 09 Aug 2024 14:27:13 GMT

Interesting hypothesis, provable with Fortran

Date a/b/cdef where a to f are 0 to 9 only

yesterday's date has the equations

a = b

a = b = sum(cdef)

ef = 3*a

8/8/2024

I had a quick look with cd = 20 I do not think there are any more like this.

If I did not have a bridge that is interesting I would code it, but the bridge beckons.

The FFT for 1 second height data at a "stationary" point in GPS looks like teh following charts. The X axis is cycles per day.

I have a Fortran program to analyze this data, it is extremely sensitive to the length of the data used for each step. Interesting. The data shows a nice curve in 3D space for the estimate of the height at different times for a slowly moving point, 7 mm over 100 days.

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

Ron_Green — Fri, 09 Aug 2024 15:18:32 GMT

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.

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

David_DiLaura1 — Sun, 11 Aug 2024 19:05:28 GMT

Mr. Nichols,

What you cite is not the issue. Intel decided to use the latest whiz-bangery in compiler technology for IFX. The problem is not that it produces a new compiler, the problem is that it is significantly less performant than IFORT. Those of us that produce commercial software cannot simply ask clients to take a 30% hit in execution time. (Or more if your code uses complex numbers and functions.) That IFORT is being deprecated BEFORE IFX is a viable replacement is the problem. Apparently, the process of getting IFX to perform as well as IFORT will take considerable time. I think it a kind of luxurious carelessness to pull IFORT from the stage before IFX is ready.

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

JohnNichols — Sun, 11 Aug 2024 19:23:12 GMT

Dear David:

Thank you for your interesting note. I have spent many decades working on various Fortran programs both for fun and for clients who pay good money for the programs. The point of speed is well made, and this and other complaints are common when new compilers are introduced both in Fortran and other languages. PowerStation drove me from Fortran for the best part of five years as it can only be described as a problem stacked on a set of other problems. There is little I can do to change Intel's mind, so one has to put up with the changes, or not change compiler, I mean the old IFORT will last a long time if you stick to one flavour, you will just miss out on fixes and updates, it is tedious but not difficult as long as you keep the necessary install programs.

We are very lucky that Intel supports Fortran, so whilst I see the point of luxurious carelessness, I think in the end we are moving into a cycle of rapid change and that is the only constant.

My absolute preference is MS Fortran 3.31 and VEdit, but I no longer have the disks or the computer.

So my odd musings, are merely a tired mind who needs a Fortran program that is 1000 times faster to do Monte Carlo analysis on bridge damage, I do not have it so something is adjusted to allow me to obtain an approximate answer. I am not happy, but one lives with what one has.

Yours in Fortran

John

PS many years ago UCB had a master's student write a program to analysis simple shells, it was great for coal bins and we started to replace the old square bins with circular bins, I was recently back in my old stamping grounds, and lo and behold someone was designing square coal bins, not a great idea. We all wish the world was a better place, but it is not. At least there is this place and Intel Fortran.

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

JohnNichols — Sun, 11 Aug 2024 19:31:04 GMT

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.

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

joerg_kuthe — Fri, 06 Sep 2024 10:39:11 GMT

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