Is there an equivalent "-ax" compiler flag for ICX/ICPX?

[TroyLowry]

My team and I are trying to upgrade from the intel classic compiler to the next-gen DPC/C++ compiler but unfortunately our journey has been fraught with issues. Currently we are stuck on a lack of an equivalent flag for `-ax` example:

-axSSE4.2,AVX,CORE-AVX-I,CORE-AVX2,CORE-AVX512

Taken directly from the documentation for the classic compiler:

Our use case: compiling with support for multiple instruction sets once and ship a single binary. If there isn't an equivalent mechanism it sounds like for each OS + ARCH we would have to have ship and deploy N times for each extended instruction set we wish to deliver, and hope our clients choose the correct one. This

Is there an equivalent flag we're missing for the next gen compiler? Recovering this old behaviour is paramount right now, as:

1. Retailoring our code to manually & explicitly target specific instruction sets is way too costly time & money-wise at this point
2. We want to switch to C++ 20 and this is the last thing blocking it (unless the classic compiler supports it)
3. The next-gen compiler has features we would love to use

[SeshaP_Intel]

Hi,

Thank you for posting in Intel Communities.

ax, Qax flag implementation is on the queue. 

We can give you a workaround with which you can build for multiple architectures.

Cpu_dispatch and ‘target’ multi-versioning are the current multi-versioning dispatch mechanisms 

(beside manual dispatch CPU-dispatch option provides multiple versions of the same function optimized for different architectures)

The difference between using cpu_dispatch and using -ax<arch> is that with -ax<arch> the compiler figures out when it’s useful to have a CPU-specific clone, 

but with cpu_dispatch the user has to guess at that and specify it at the source level for each function to be multi-versioned.

With CPU-dispatch we can do something like:

__attribute__((cpu_dispatch(list, of, architectures, and, things, here)))

void the_function();

__attribute__((cpu_specific(list, of, architectures, and, things, here)))

void the_function() { the implementation; }

If we have a special implementation for one of those, we can remove it from the cpu_specific declaration, and create a ‘new’ cpu_specific declaration with only that architecture (or a subset of architectures).

Hope this helps to resolve your issue. As soon as the ax, Qax flag is implemented it will be a part of the release notes.

https://www.intel.com/content/www/us/en/developer/articles/release-notes/intel-oneapi-dpc-c-compiler-release-notes.html

Thanks and Regards,

Pendyala Sesha Srinivas

[TroyLowry]

Is there any ETA on when this feature is planned to be released? The above solution may technically work for our own code but not for code that we are not allowed to modify (say recompiling licensed third party libraries), however if this feature is actively being worked on and would likely be released within the next 12 months we might be OK sticking with ICC a little while longer

[SeshaP_Intel · Accepted solution]

Hi,

We are not sure of ETA.

But when the respective flags are released for next-gen compilers they will be part of the release notes. Please find the link below.

https://www.intel.com/content/www/us/en/developer/articles/release-notes/intel-oneapi-dpc-c-compiler-release-notes.html

Thanks and Regards,

Pendyala Sesha Srinivas

[SeshaP_Intel]

Hi,

We are closing this issue for now. If you need any additional information, please post a new question as this thread will no longer be monitored by Intel.

Thanks and Regards,

Pendyala Sesha Srinivas

[AndrewC]

I am interested if you found the Qax options actually gave you any worthwhile performance benefits? I have tried this option and found that it gave minimal , if any,  runtime benefits while increasing compile times with serious code-bloat as well as being buggy.

We use MKL a lot which switches to the most optimal kernel in any event.

With ICX, the release notes suggest making /QAVX the minimum because  many optimizations are only activated at that level.  If your code is performance critical, then requiring an AVX capable processor only excludes some machines >10 years old.

[TroyLowry]

Unfortunately I don't have a firm answer for this, as this leg of the work was done by my superiors long before i was brought on at my current job. They do tell me that it made a worthwhile difference though (scientific computing, running for hours to days).

However when comparing 2 builds of our software: 1 compiled with ICC and the other with ICX, both using the 2022.3.0 release of OneAPI, the ICX version performs roughly 10% worse. The compilation flags are essentialy the same, however some flags behave differently between them, as well as some flags were not supported or only accept certain arguments.

[AndrewC]

Well on my first try with ICX I was seeing about 10% poorer performance. But if you read the ICX release notes they state that many  optimizations are only active at /QAVX is on. After turning on /QAVX and fixing problems with MKL_DIRECT_CALL not being activated for ICX , I now have slightly better performance from ICX vs ICL. 

Ultimately ICX "is" Clang under the hood so many of the optimizations ( and some bugs ...) come from Clang  - which is under very active development much more so than ICL ever was.