Community
cancel
Showing results for 
Search instead for 
Did you mean: 
xunxun
Beginner
97 Views

ICC 12 /arch and /Qax options

Jump to solution
Dear Forum,

I want to ask some issues about icc12 option /arch and /Qax

If I use
/arch:SSE2 /QaxSSE2,SSE3,SSSE3,SSE4.1,SSE4.2,AVX,CORE-AVX2,CORE-AVX-I

on my computer (cpu is intel core2)

I don't know which instruction set the program use on my computer.

If I move the program built to another computer (such as athlon-xp), which instruction set does the program use?

If I use
/arch:SSE3 /QaxSSE2,SSE3,SSSE3,SSE4.1,SSE4.2,AVX,CORE-AVX2,CORE-AVX-I

The state is the same?

Thanks,
xunxun



0 Kudos

Accepted Solutions
Georg_Z_Intel
Employee
97 Views
Hello,

I'm staying with your example using /arch & /Qax all-together. The semantic changes when you use them differently. In the compiler documentation all the different combinations are described nicely (look for Code Generation Options/ax, Qax).

Using /Qax tells the compiler to produce a baseline version of code that's characterized by the setting of /arch and can be executed by Intel & non-Intel processors supporting that extension.
The extensions named with /Qax make the compiler create different versions of the code if there's a performance benefit (so, might not always take place). In contrary to above those versions are only for Intel processors (needs to identify CPU type at runtime!).

Staying with your two examples:
The first one, when executed on Intel Core2, would not use the baseline path but at least SSE3 (newer versions might also have SSE4.1). If you have an Intel Core iX CPU it might also use SSE4.2 or AVX. There's no HW out yet for the other AVX versions - reserved for the future.

The second one (note that you used /arch:SSE3 there!), creates a baseline path for SSE3 and any non-Intel processor is using that, no matter what you specify with /Qax. This would be the case for you when running on AMD*.

Hope that helped,

Georg Zitzlsberger

View solution in original post

12 Replies
Georg_Z_Intel
Employee
98 Views
Hello,

I'm staying with your example using /arch & /Qax all-together. The semantic changes when you use them differently. In the compiler documentation all the different combinations are described nicely (look for Code Generation Options/ax, Qax).

Using /Qax tells the compiler to produce a baseline version of code that's characterized by the setting of /arch and can be executed by Intel & non-Intel processors supporting that extension.
The extensions named with /Qax make the compiler create different versions of the code if there's a performance benefit (so, might not always take place). In contrary to above those versions are only for Intel processors (needs to identify CPU type at runtime!).

Staying with your two examples:
The first one, when executed on Intel Core2, would not use the baseline path but at least SSE3 (newer versions might also have SSE4.1). If you have an Intel Core iX CPU it might also use SSE4.2 or AVX. There's no HW out yet for the other AVX versions - reserved for the future.

The second one (note that you used /arch:SSE3 there!), creates a baseline path for SSE3 and any non-Intel processor is using that, no matter what you specify with /Qax. This would be the case for you when running on AMD*.

Hope that helped,

Georg Zitzlsberger

View solution in original post

xunxun
Beginner
97 Views
Thanks, Georg.

If I use /arch:SSE2/SSE3, this instruction set can be generated and runned on all Intel or AMD CPU what support it.

If I use /Qax..... additionally, they may be better on better Intel CPU, but on AMD they are useless.

Am I right?


Regards,
xunxun
TimP
Black Belt
97 Views
If you use /Qax option, the AMD execution will take the secondary code path (SSE2 by default; you have options to change it). Developers often prefer a single arch option which is suitable for all CPUs they intend to support. It's not unusual that /arch:SSE2 or SSE3 is superior on Intel CPUs as well. the more paths you chose, the more testing you should undertake. There is only one AVX option suitable for any CPUs to be marketed this year. /QxSSSE3 works on all core 2 CPUs; /QxSSE4.1 would be good for the recent Core 2 models. You are right that if you specify too many alternaties you may find it more difficult to check which one is in use, and, should you be interested, which ones actually resulted in a separate code path.
xunxun
Beginner
97 Views
Thanks, TimP

I also have a quesition.

If I use icc x64 edition, are /arch:SSE2 and /arch:SSE3 the same?

I think all x64 cpu support SSE2 and SSE3.


Regards,
xunxun
Om_S_Intel
Employee
97 Views
The /arch:SSE2 and /arch:SSE3 are not same.
xunxun
Beginner
97 Views
The /arch:SSE2 and /arch:SSE3 are not same.

But I note it's X64 edition.

I think x64 cpu all support SSE2 and SSE3, so I think /arch option is useless on X64.

xunxun
Beginner
97 Views
Quoting xunxun
The /arch:SSE2 and /arch:SSE3 are not same.

But I note it's X64 edition.

I think x64 cpu all support SSE2 and SSE3, so I think /arch option is useless on X64.

VC2010 X64 Compiler has /favor:blend /favor:AMD64 /favor:INTEL64, but no /arch option.

Does icc have the similar option?

Georg_Z_Intel
Employee
97 Views
Hello,

on top of my head (please correct me if I'm wrong):
All Intel processors using Intel 64 (x64) have SSE3 (& SSE2).
The first version of AMD* processors with AMD64 (x64) only had SSE2. They introduced SSE3 with a later generation.

So, no, not all 64 bit CPUs support both SSE2 & SSE3.

To reply #2 above: Yes, that's right. Please keep in mind that the alternative versions with /Qax only execute on Intel CPUs. If the CPU cannot be detected (no Intel CPU), the baseline version is used. The baseline is never checked! Hence, if you say /arch:SSE3 and the processor does not support that your application will crash. Hence /arch should be conservative.

Best regards,

Georg Zitzlsberger
TimP
Black Belt
97 Views

on top of my head (please correct me if I'm wrong):
All Intel processors using Intel 64 (x64) have SSE3 (& SSE2).
The first version of AMD* processors with AMD64 (x64) only had SSE2. They introduced SSE3 with a later generation.

So, no, not all 64 bit CPUs support both SSE2 & SSE3.

To reply #2 above: Yes, that's right. Please keep in mind that the alternative versions with /Qax only execute on Intel CPUs. If the CPU cannot be detected (no Intel CPU), the baseline version is used. The baseline is never checked! Hence, if you say /arch:SSE3 and the processor does not support that your application will crash. Hence /arch should be conservative.

Yes, this is correct. According to both Microsoft X64 and linux x86_64 definition, SSE2 is the base architecture, and the MSVC x64 compiler has no other /arch option. As mentioned above, MSVC has no SSE3 code generation (except by SSE3 intrinsics). The primary reason for /arch:SSE3 option is to support auto-vectorization with operations on complex data types. If you don't have such data types, the SSE2 (default "baseline" for /Qax....) is good enough on AMD.
As George mentioned, if you don't need to support the early AMD CPUs, you can set the baseline to SSE3.
Georg_Z_Intel
Employee
97 Views
Hello,

there's no /favor option. Our compiler creates different code versions and detects the underlying CPU at runtime. As a user you don't need to worry about different 64 bit flavors (Intel 64 & AMD64) - it should be transparent to you.
Even though /arch creates a baseline version for some instruction set extension it might still do detection for whether to use Intel 64 or AMD64 (both differ slightly). However, that's up to our compiler and should make it easier for you.

Best regards,

Georg Zitzlsberger
TimP
Black Belt
97 Views

I find George's comment somewhat confusing. ICL (with /arch: options SSE2 and SSE3) avoids code generation which favors AMD or Intel CPUs; the same generated code should work well on both, so there is no need for a /favor option. In fact, I think VS2010 (or even VS2008 SP1) do a reasonable job of not depending on /favor for recent Intel CPUs.
There is some AMD vs. Intel64 run-time switching in the run-time libraries, but not in the compiler generated code when a single /arch is set. Math library switching could be avoided by compiling with
/Qimf-arch-consistency:true
the main usefulness of this on AMD (or an old Intel) CPU being as insurance against a bad choice of library.
xunxun
Beginner
97 Views
Thanks, all.
I understand what I should do.