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.

[Steve_Lionel]

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.

[jimdempseyatthecove]

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

[Ron_Green]

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.  

[Ron_Green]

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.  

[Neels]

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.

[David_DiLaura1]

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.

[Umar__Sait]

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.

[Cameron]

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

[Ron_Green]

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.

[sindizzy]

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

[Ron_Green]

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.

[Andrew_Smith]

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.

[JohnNichols]

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?

[JohnNichols]

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. 

[David_DiLaura1]

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.

[JohnNichols]

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. 

[J_Kuthe]

Hi David,

is it really that bad with IFX? I recently run Polyhedron's Benchmarks to compare IFX and IFORT and the result doesn't proove the performance loss you state. See for yourself:

https://polyhedron.com/fortran/performance-ifx-vs-ifort/

or here

Or does the performance loss of IFX vs IFORT only occur when using COMPLEX datatypes heavily?

Joerg

[Umar__Sait]

In our experience it is the complex types mainly. It is also interesting that I have couple of AMD machines (threadripper) and using AMD's aocc compiler gives the same slowdown compared to using ifort on the AMD machine! Seems to be a problem of all llvm based compilers.

[David_DiLaura1]

Joerg,

The results we're seeing in performance differences between IFORT and IFX are in two large commercial programs. Importantly, both have large loops that have been threaded using OpenMP. This aspect of your test suite (https://polyhedron.com/fortran-compiler-comparisons/) isn't clear. There, it states that autoparallel was set when you ran the tests. We find autoparallelization to have little effect in large systems, since the benefit of threaded almost always requires 'hand coding' using OpenMP for large loops where performance gain is significant. Autoparallelization merely nibbles at the edges -- as it were.

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