ifx compiler options

[prop_design]

hi,

so i see you are going to drop ifort. i have tested ifx some and have had some issues. do you know if the following ifx compiler options are still not available:

ifx: command line warning #10152: option '/QaxSSE2' not supported
ifx: command line warning #10148: option '/Qprec-sqrt' not supported

ifx: command line warning #10148: option '/Qpar-affinity:core,scatter' not supported
ifx: command line warning #10148: option '/Qparallel' not supported
ifx: command line warning #10148: option '/Qopt-report-phase=par' not supported

the last version of ifx i tested was 2023.2.1

thanks,

anthony

[andrew_4619]

The 2024 option  list is at https://www.intel.com/content/www/us/en/docs/fortran-compiler/developer-guide-reference/2024-0/alphabetical-option-list.html

[prop_design]

thanks @andrew_4619 

this is  helpful

[Steve_Lionel]

/QaxSSE2 makes no sense for ifx, as it is x64 and SSE2 is a baseline.

I'm a bit astonished that auto-parallel doesn't seem to be supported yet, especially as I don't see mention of that in Ron's blog post, nor is it excluded in the command line options documentation.

[prop_design]

thanks. i see sse3 is in the list that @andrew_4619 provided a link to. i can bump up to that. i distribute my code at the oldest possible level, to support the most processors. however, i also discovered an odd behavior in ifort when using CORE-AVX512. i was getting slightly different results across different programs that i have. one variable is the same across programs, thus computed with the same code. when using CORE-AVX512, that variable would vary code to code. which it shouldn't. with SSE2 that variable came out the same. it was a small difference. but still, it was a weird and undesirable behavior.

The auto parallel stuff has never worked good for me. So that is a trivial difference, in my case. but, as a whole, the missing compiler options are why i never pulled the trigger on trying to switch to ifx. now i'm going to be forced to switch. so i figured i would ask about them. it would be a lot easier to switch if all the same compiler options were available.

[andrew_4619]

Keep in mind that the Ifort will be come deprecated but that doesn't mean you can't use the last level for quite some time. The thing that is lagging most in IFX  I think is optimisation stuff but I expect that will start to move on soon also, lets face it you need to have stable and complete base functionality before you look to making it optimise better.

[prop_design]

i think i need to try the latest version. the list you posted has Qprec-sqrt shown. that is the main one that is missing for me. updating to sse3 is the only other change i would have to make. ifx isn't too different from ifort in terms of exe speed. this last test i did showed it a little slower than ifort. however, it's not a big deal for me.

[prop_design]

hmm. well that was a waste of time. i updated everything, which takes about an hour, and still have the same issue. In particular:

ifx: command line warning #10148: option Qprec-sqrt' not supported

I don't understand why you are forcing this change on everyone when the ifort options aren't there. seems very premature.

[andrew_4619]

Qprec-sqrt only seems to disable optimisations that favour speed over precision.  This case in IFX might be that such optimisations are not implemented as yet so the option would be pointless.

As I said earlier all the depreciation of IFORT means in reality is that there will be no further updates after a cut-off date some time in the future so the material effect is maybe 2 or 5 years away when you will need to run an out of support VS to be able to run the 'old' IFORT. That is plenty of time for IFX development. You didn't waste you're time you got an updated version of IFX and IFORT installed.

Currently I don't use IFX because there are some debugger integration issue that need addressing but I think they are already fixed for the next release, it does however work fine for my production builds but I am reticent to use IFORT for debug and IFX for release so I will wait some more.

[prop_design]

thanks again @andrew_4619 

i will check to see if any of the answers are different. i think that would prove what you are saying about the precise square root option being useless. i just finished checking about my previous oddity. it is no longer present. i get the same answers with sse2 and core-avx512 now. well almost the same. the only other difference i think is really due to rounding error introduced when transferring a variable from one code to the others.

@Steve_Lionel 

i guess i'm confused as to the sse2 vs sse3 limitation. it's true that sse3 came out with x64. however, i use ifort with sse2 on 64bit builds. i never build on 32bit. so i'm wondering why ifort can build sse2 on 64bit, but ifx can not? for that matter, why can't both go back to SSE. the further back the better, in my case. that means more CPUs can run my code. SSE3 goes back to 2004 though, so that's pretty far back. it's probably a trivial difference, in reality. just curious as to why this limitation exists

[Steve_Lionel]

I can't explain why the option isn't supported by ifx. If it had been up to me, I would have silently ignored the option. It's not that ifx can't generate SSE2 - it can. But there's no point in asking for auto-dispatch on CPUs that don't support SSE2 as there aren't any x64 systems without SSE2. /QxSSE2 also gives a needless error, though I suppose its only effect would be to exclude non-Intel CPUs.

Perhaps I'll give @Lorri_M_Intel  a hard time about this. I'm more concerned by the lack of documentation I can find about /Qparallel not being supported.

[prop_design]

by auto parallel not doing anything, i inadvertently found two key ways to speed up my code. this was to add the options:

/Qoverride-limits

/Qvec-

the latest manual says /Qoverride-limits is only for ifort. however, it seems to function with ifx.

i'm getting really fast speeds out of ifort now. it's faster than ifx. ifort was faster with sse2. ifx was much slower with sse3 and sped up a lot with avx512. so i would loose a lot of compatibility if i went with ifx and it would still be slower than ifort with sse2. so this forced switch isn't looking good. at least for my code.

@andrew_4619

i checked the results and what you said seems to be true. there is no difference in my results with /Qprec-sqrt

[prop_design]

I spent the day updating my compiler comparisons. I have been doing these for 15 years. This is the most recent version. I attached the Libre Office Calc file. You should be able to open it in Excel. ifort is still the king. I also attached the bat files, in case you want to examine things more. The program used for testing is PROP_DESIGN_MAPS. It is available on my website (as public domain software).

So the main point is that; although I could switch to ifx, why would I. This forced migration seems premature to me.

For some reason auto parallel will not function at all. It says to try adding /Qoverride-limits. But it doesn't help. When I activate auto parallel it essentially turns of ipo, auto vec, and auto parallel. It took me a really long time to realize what was going on. It shows as a speedup, but in reality it has nothing to do with actually using auto parallel.

My earlier observation about turning off auto vec seems to be false now. Maybe I was doing an apples to oranges comparison yesterday. Not sure. But it's definitely gone today and I know I'm doing an apples to apples comparison now.

The Intel Fortran group deserves a lot of praise. I don't think people realize how badly you spank other Fortran compilers.

ps

the *.ods file extension is for LibreOffice Calc

12/11/23 Update; I updated the spreadsheet comparison. More plots were added.

[prop_design]

I created a download of my benchmark, to make it easier for people to duplicate. It is available here:

https://propdesign.jimdofree.com/fortran-benchmarks/

If I make any updates, they will be posted there.

[Steve_Lionel]

Nothing is being forced on you - yet. The ifort code generator has always been a terrible design (I've heard it likened to someone's college project), and is difficult to maintain. (I could say that Intel would have been far better off to ditch IL0 for the DEC GEM backend, when the DEC compiler team moved to Intel, but that ship has sailed.) That most of the industry is converging on LLVM, a more modern design, means quick improvement. LLVM suffers in that it was (and is still largely) C-focused, so making Fortran work well with it requires more effort.

[Barbara_P_Intel]

Have you read the ifort to ifx Porting Guide? There are a lot of tips to help with the move to ifx.

/Qparallel is only supported with ifort. See the Fortran Developer Guide.

On Linux, ifx -qnextgen-diag lists the compiler options that will be coming and those that are removed. It works on Windows, too.

[prop_design]

thanks @Barbara_P_Intel  no i didn't see that document. i will take a look.

[Barbara_P_Intel]

According to the Fortran Developer Guide, /Qprec-sqrt is only supported with ifort.

[Steve_Lionel]

This is interesting - does it mean that ifx can't parallelize DO CONCURRENT the way ifort can, or does it do it automatically?

[prop_design]

@Steve_Lionel 

the only thing i can tell about auto parallel is it has never worked with my codes. from what little i know, the feature can't deal with loop nests. however,  auto parallel and ifort has occasional done trival loops. currently though, it's not even doing that. something seems to have regressed. gfortran has had similar issues. can't deal with loop nests, only does trival loops, sometimes didn't work at all. it seems this feature isn't really useful and for some reason breaks randomly among releases. the best thing i have found for my codes is just to use O3.

i have been updating the files i posted, all day. i just updated them again not long ago. the results are interesting and pretty typical from what i have seen going back over a decade. i recently was able to add flang in there. it seems no different than gfortran. i have a problem with variability in the results. so i do multiple runs of each case and keep the fastest speed i seen. the diff between flang and gfortran is smaller than the randomness in my runtimes. modern cpus make this type of thing  hard to do because they throttle and don't run constant like OG cpus.

one of the newer things i looked at was the speed differences with no optimizations. i think that is the most fascinating. intel is way faster than gfortran or flang in this instance. so they are starting from a much slower position.  O1, O2, and O3 aren't much different for each compiler. however, O3 seems to be just slightly the best. somehow intel fortran just has a really strong starting speed.

polyhedral was showing huge gains with a code i sent them and i couldn't duplicate their results. they wouldn't respond to my requests to explain their results or update to a new version of my code or just simply take down their results. they are basically bogus. i've never got anything good out of auto parallel. even with that, intel fortran is by far the way to go. much faster than other compilers i have tried. i used to also use the pgi compiler for awhile. it was also slower than intel fortran but still faster than gfortran. basically, just about everything is faster than gfortran and nothing is faster than intel fortran. by faster i mean the runtimes you get out of your exe files. not compiler time. compiler times for any compiler aren't something i keep track of.

[Barbara_P_Intel]

@Steve_Lionel, the compiler will attempt to parallelize the DO CURRENT construct if the -qopenmp (/Qopenmp) compiler option is used. That's the same for both ifx and ifort.

With ifx compiling with -fopenmp-target-do-concurrent (/Qopenmp-target-do-concurrent) will attempt to convert the DO PARALLEL to an OpenMP TARGET offload region.