2

I am currently building a software from source that is performance critical for me. Therefore I want to optimize it for running on my specific Intel CPUs. The building process requires that I set the -march and -mtune flag.

If on my processor node i use

gcc -march=native -Q --help=target|grep march
gcc -mtune=native -Q --help=target|grep mtune

I get "core-avx2" for march and "generic" for mtune. However with 

cat /proc/cpuinfo

I get:

processor   : 23
vendor_id   : GenuineIntel
cpu family  : 6
model       : 63
model name  : Intel(R) Xeon(R) CPU E5-2670 v3 @ 2.30GHz
stepping    : 2
microcode   : 0x3d
cpu MHz     : 2599.993
cache size  : 30720 KB
physical id : 1
siblings    : 12
core id     : 13
cpu cores   : 12
apicid      : 58
initial apicid  : 58
fpu     : yes
fpu_exception   : yes
cpuid level : 15
wp      : yes
flags       : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 sdbg fma cx16 xtpr pdcm pcid dca sse4_1 sse4_2 x2apic movbe popcnt xsave avx f16c rdrand lahf_lm abm epb intel_ppin ssbd ibrs ibpb tpr_shadow vnmi flexpriority ept vpid fsgsbase tsc_adjust bmi1 avx2 smep bmi2 erms invpcid cqm xsaveopt cqm_llc cqm_occup_llc dtherm ida arat pln pts
bogomips    : 4599.35
clflush size    : 64
cache_alignment : 64
address sizes   : 46 bits physical, 48 bits virtual
power management:

By going to the homepage of Intel(R) Xeon(R) CPU E5-2670 v3 @ 2.30GHz (https://ark.intel.com/content/www/de/de/ark/products/81709/intel-xeon-processor-e5-2670-v3-30m-cache-2-30-ghz.html) I found out: Codename -> Products formerly haswell

If I use

gcc -march=haswell -Q --help=target|grep march
gcc -mtune=haswell -Q --help=target|grep mtune

I get "haswell" for both. So shouldn't I actually use haswell as march instead of core-avx2? What is the best possible choice?

Btw, I am using GCC 4.8.5 on CentOS7.

Thanks!

Edit:

gcc -march=native -Q --help=target | grep -- '-march=' | cut -f3

-> core-avx2

gcc -mtune=native -Q --help=target | grep -- '-mtune=' | cut -f3

-> generic

Hadi Brais
  • 22,259
  • 3
  • 54
  • 95
tre95
  • 433
  • 5
  • 16
  • 2
    On x86 processors, just use `-march=native`. GCC will handle the rest by setting `arch` and `tune` to same value. ARM is trickier since GCC sometimes segfault's when using `-march=native`. You should also use a modern GCC or maybe Clang. Clang creates better code than GCC with some SIMD source code. You will need to benchmark to determine which performs best for your code. – jww Jul 03 '19 at 18:16
  • Hi, thanks for your response! Unfortunately I must build the software on my local machine (due to missing rights on the cluster executing the code later on) using a Docker container, therefore native is no choice for me, as it would optimize for my local machine. Also I must stick to GCC 4.8.5 because many people work on this project and they once tried to upgrade gcc which led to a broad number of incompatibilities within the project. – tre95 Jul 04 '19 at 06:59
  • Then it sounds like this statement is incorrect: *"... I want to optimize it for running on my specific Intel CPUs"*. You should probably update your question. – jww Jul 04 '19 at 07:02
  • Yes, I am sorry, I meant for the CPUs I want to deploy my software on. The listed specifications above are those of the target platform for that I want to optimize. – tre95 Jul 04 '19 at 07:02

2 Answers2

3

In the gcc version you're using, Haswell was called core-avx2. Other microarchitectures had also crappy names. For example, Ivy Bridge, Sandy Bridge, and Westmere were called, core-avx-i, corei7-avx, and corei7, respectively. Starting with gcc 4.9.0, the actual names of the microarchitectures are used, so gcc will print Haswell when using gcc -march=native -Q --help=target|grep march on a Haswell processor instead of core-avx2 (see the patch).

When passing -mtune=native to gcc and the host processor is not known to the version of gcc you're using, it will apply generic tuning. Your processor model (63) is only known to gcc 5.1.0 and later (see the patch).

The name-printing part of -Q --help=target has to pick some name for -march=native. For CPUs too new for your GCC to recognize specifically, it will pick something like Broadwell if the processor supports ADX, or the microarchitecture that supports the highest SIMD extension (up to AVX2) that is supported on the host processor (as determined by cpuid).

But the actual effect of -march=native is to enable all the appropriate -mavx -mpopcnt -mbmi2 -mcx16 and so on options, all detected separately using cpuid. So for code-gen purposes, -march=native always works for enabling ISA extensions that your GCC knows how to use, even if it doesn't recognize your CPU.

But for setting tune options, -march=native or -mtune=native totally fails and falls back to generic when it doesn't recognize your CPU exactly. It unfortunately doesn't do things like tune=intel for unknown-Intel CPUs.

On your processor, gcc knows that it supports AVX2, so it assumes that it is a Haswell processor (called core-avx2 in your gcc version) because AVX2 is supported starting on Haswell, but it doesn't know for sure that it is actually a Haswell processor. That's why it applies generic tuning instead of tuning for core-avx2 (i.e., Haswell). But in this case, I think this would have the same effect as tuning for core-avx2 because, to that compiler version, only Haswell supports AVX2 and the compiler knows that the host processor supports AVX2. In general, though, it may not tune for the native microarchitecture even if -march was guessed correctly on an unkown CPU.

(Editor's note: no, tune=generic doesn't adapt to which instruction-set options are enabled. It's still fully generic tuning, including caring about CPUs like AMD Phenom or Intel Sandybridge that don't support AVX2. See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80568 and Why doesn't gcc resolve _mm256_loadu_pd as single vmovupd?.

This is one reason why you should use -march=native or -march=haswell (with a new enough gcc), not just -mavx2 -mfma. The other reason is that you're probably going to forget -mbmi2 -mpopcnt -mcx16, and maybe even forget -mfma)

Peter Cordes
  • 328,167
  • 45
  • 605
  • 847
Hadi Brais
  • 22,259
  • 3
  • 54
  • 95
  • *it will choose the microarchitecture that supports all the instructions* That's not exactly right. The `-march=native` part doesn't choose a microarch and use those settings, it simply *checks* for each CPU feature GCC knows about using `cpuid` results. So inside a VM that chooses a weird set of things to expose via CPUID, `-march=native` could maybe enable AVX2 but not `popcnt` or AES, if that's what CPUID reported, even though no `-march=xyz` setting could do that. – Peter Cordes Jul 03 '19 at 19:52
  • But yes, for *tune* settings GCC has to recognize the processor specifically, and falls back to `generic` if your CPU is too new for GCC to know about. It could be argued that identifying it as a recent Intel mainstream CPU is possible, and that choosing the latest such tuning GCC knows about (e.g. `tune=ivybridge`) would be more useful. Or at least `-mtune=intel`. – Peter Cordes Jul 03 '19 at 20:00
  • @PeterCordes Right, but gcc will still print "Haswell" if the processor supports AVX2 but not `popcnt`, for example. Of course, it will not use `popcnt` in that case. Good point, though. This is important to keep in mind. I don't think it's a good idea to tune for an older microarchitecture (such as Ivy Bridge) if gcc doesn't know the model of the host processor because this may result in worse performance than generic tuning on a different microarchitecture (such as Haswell). – Hadi Brais Jul 03 '19 at 21:08
  • The way you phrased it in your answer makes it sound like it still picks a set of extensions for a specific known uarch. Like that ADX support would cause GCC to enable AVX2 regardless of what `cpuid` says about AVX2. That guesswork is probably only in the name-printing code this answer is asking about, not in the important part of `-march=native` that really matters most of the time. Use `-fverbose-asm` and look at the asm comments to see what gcc detected with enabled/disabled `-m` options. – Peter Cordes Jul 03 '19 at 21:12
  • @PeterCordes Agreed, the phrasing was not right. I think it's fixed now. – Hadi Brais Jul 03 '19 at 21:14
  • It was still very misleading, IMO. I made an edit with what I had in mind. – Peter Cordes Jul 03 '19 at 21:47
  • Hi, so first of all thanks for the very detailed answer, I learnt a lot by reading. So some additional information - I must use GCC 4.8.5 for two reasons. First of all the software I build is Tensorflow, and Google states that the build of the required version (1.12) has only been tested with GCC 4.8.5. I also tried with a newer GCC version, which leads to the problem that Tensorflow is compiled to use GLIBCs and GLIBCXXs that my target hardware (a computing cluster using CentOS 7 and GCC 4.8.5) is not compatible to. – tre95 Jul 04 '19 at 07:14
  • As stated in my comment to the first comment above, I / we can not update GCC 4.8.5 as it leads to several issues with other parts of our software. Moreover I do not have the rights to build on the target platform, which makes it impossible to use march=native, as I build within a docker container (CentOS 7.6, GCC 4.8.5) on my local machine, using even older Intel processors. – tre95 Jul 04 '19 at 07:16
  • Meanwhile I tried to do the build process with GCC 4.8.5 while using "haswell" for march and mgeneric. As expected (I guess, from your answer?) I get this error: ```error: bad value (haswell) for -march= switch```. So that is the case where GCC does not know haswell I guess, from reading your response. To finish off, regarding all the circumstances and reqirements I am facing, what is the best solution? The build worked in my docker container using 1) march=core-avx2 and mtune=core-avx2 as well as 2) march=core-avx2 and mtune=generic. Is there a superior way to do it? – tre95 Jul 04 '19 at 07:19
  • Flags by ```at /proc/cpuinfo``` - Part 1: ```fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 sdbg fma cx16 xtpr pdcm pcid dca sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer xsave avx f16c rdrand lahf_lm abm epb intel_ppin``` – tre95 Jul 04 '19 at 07:35
  • Flags Part 2: ```ssbd ibrs ibpb stibp tpr_shadow vnmi flexpriority ept vpid fsgsbase tsc_adjust bmi1 avx2 smep bmi2 erms invpcid cqm xsaveopt cqm_llc cqm_occup_llc dtherm ida arat pln pts spec_ctrl intel_stibp flush_l1d``` – tre95 Jul 04 '19 at 07:35
  • Would it be recommendable in this situation to use the flags for the available instruction set architectures? From my last two comments I guess these would then be ```sse sse2 fma sse4_1 sse4_2 avx avx2```? Sorry for the many questions but for somebody totally unexperienced in high performance computing and hardware stuff this is hard to understand... – tre95 Jul 04 '19 at 07:57
  • 2
    @tre95 If you know that the code will only run on processors that are AVX2-capable, then use `-march=core-avx2` (there is no need for an explicit `-mtune=core-avx2` because it is implied in this case). – Hadi Brais Jul 04 '19 at 09:09
1

Btw, I am using GCC 4.8.5 on CentOS7.

If performance is critical, you should use a more recent version of GCC. The 4.8 release series dates back to 2013, and lacks many performance enhancements that are present in current versions. Current versions have significantly expanded tuning options for x86, including -march settings for many processor families that didn't exist in 2013.