编译器优化：g++；比英特尔慢 最近我在C++中获得了一个双引导的计算机。Windows上，我在英特尔上使用了英特尔C++编译器和G++。 我的程序主要包括计算（带数值积分的定点迭代算法等）。 我原以为我可以在linux上获得接近windows的性能，但到目前为止我没有：对于完全相同的代码，用g++编译的程序比用intel编译器编译的程序慢2倍左右。从我所读到的，icc可以更快，甚至可能高达20-30%的收益，但我没有读到任何关于它是两倍快的东西（通常我读到两者应该相等）

起初，我使用的标志大致相当：

icl/openmp/I“C:\boost\u 1\u 61\u 0”/fast program.cpp

及

g++-o program.cpp-std=c++11-fopenmp-O3-ffast数学

根据其他几个主题的建议，我尝试添加/替换其他几个标志，如：-funsafe math optimizations，-march=native，-fwhole program，-Ofast等，但性能仅略有提高（或没有提高）

icc真的更快了还是我遗漏了什么？ 我对linux相当陌生，所以我不知道，也许我忘了正确安装一些东西（比如驱动程序），或者在g++中更改一些选项？我不知道情况是否正常，这就是为什么我更愿意问的原因。尤其是因为我更喜欢使用linux来编写理想的代码，所以我更希望它能够达到最新的速度

< > >编辑：我决定在Linux上安装最后一个英特尔编译器（英特尔编译器C++ 17，UpDea4）来检查。我最终得到了缓和的结果：它并不比gcc做得更好（事实上甚至更糟）。 我运行了交叉比较linux/windows-icc/gcc-parallelized与否，使用了本文前面提到的标志（为了进行直接比较），下面是我的结果（运行1次迭代的时间以毫秒为单位）：

普通循环，无并行化：

• 窗口：
  gcc=122074；icc=68799
• Linux:
  gcc=_91042；icc=92102

并行化版本：

• 窗口：
  gcc=27457；icc=19800
• Linux:
  gcc=27000；icc=30000

总而言之：有点乱。 在linux上，gcc似乎总是比icc快，尤其是在涉及并行化的情况下（我运行它的时间更长，差异比这里的要大得多）。
在windows上，情况正好相反，icc显然主导着gcc，尤其是在没有并行化的情况下（在这种情况下，gcc需要很长时间来编译）

最快的编译是在windows上通过并行化和icc完成的。我不明白为什么我不能在linux上复制它。我需要做些什么（ubuntu 16.04）来加快我的进程吗？
另一个不同之处是，在windows上，我使用较旧的intel composer（composer XE 2013），并调用“ia32”而不是intel64（我应该使用的是intel64），而在linux上，我使用昨天安装的最新版本。在linux上，“英特尔编译器17”文件夹位于我的第二个hdd（而不是安装linux的ssd）上，我不知道这是否也会减慢速度。
你知道问题出在哪里吗

编辑：精确硬件： Intel（R）Core（TM）i7-4710HQ CPU@2.50GHz，8个CPU，4个内核，每个内核2个线程，体系结构x86_64 -Linux Ubuntu 16.04，带有gcc 5.4.1和英特尔编译器17（更新版4） -Windows 8.1，英特尔Composer 2013

编辑：代码很长，下面是我正在测试的循环的形式（即，我的定点迭代中只有一次迭代）。我想这是非常经典的。。。我不确定它能给这个话题带来什么

// initialization of all the objects...
// length_grid1 is about 2000
vector< double > V_NEXT(length_grid1), PRICE_NEXT(length_grid1);
double V_min, price_min; 
#pragma omp parallel
{ 
#pragma omp for private(V_min, price_min, i, indexcurrent, alpha, beta)
    for (i = 0; i < length_grid1; i++) {
         indexcurrent = indexsum[i]; 
         V_min = V_compute(&price_min, indexcurrent, ...);
         V_NEXT[indexcurrent] = V_min; PRICE_NEXT[indexcurrent] = price_min;
     }
 }// end parallel

优化的函数（intra_值）在计算方面相当复杂（从预编译的网格中选择网格点（行索引），然后涉及大量数值积分等）。

请注意，“快速数学”打破了一些语言规则以获得快速代码，在某些情况下可能产生不正确的结果

还请注意，

-O3

不能保证比

-O2

或任何其他优化级别更快（取决于您的代码）-您应该测试多个版本

您可能还希望启用

-Wl，-O1

-链接器还可以进行一些优化

您可能还想尝试使用LTO（链接时间优化）构建—它通常可以产生显著的改进

我知道这并不能回答你的问题。但它应该给你一些东西玩：-）

---

此外，gcc的进步也相当快。如果尚未使用7.1，则可能需要尝试更新的版本。也；尝试第三个数据点的叮当声。此外，如果愿意，您可以在Linux上使用icc。

看起来您正在使用OpenMP，因此我怀疑差异在于OpenMP实现，而不仅仅是优化代码的质量

众所周知，英特尔的OpenMP运行时具有相当高的性能，而GCC的性能很好，但并不出色

---

OpenMP程序具有非常不同的性能特征，它们不仅仅取决于编译器优化循环或内联函数调用的能力。OpenMP运行时的实现非常重要，线程和同步原语的操作系统实现也很重要，这在Windows和GNU/Linux之间是非常不同的。

您可能希望尝试在Windows上用GCC编译代码。你可以使用“用g++编译大约慢2倍”，我想你的意思是编译程序慢，而不是编译慢。说编译速度慢意味着编译代码需要更长的时间，但我不认为这就是你所说的你在英特尔CPU上运行它吗？如果没有弄错的话，ICC可以为英特尔处理器提供更好的优化（与自身相比），并且可能比其他编译器更快（因为他们自己知道如何进行优化）

double V_compute(double *xmin, int row_index, ... ) {
double x1, x2, f1, f2, fxmin;
// golden_ratio=0.61803399; 
x1 = upper_bound - golden_ratio*(upper_bound - lower_bound);
x2 = lower_bound + golden_ratio*(upper_bound - lower_bound);

// Evaluate the function at the test points
f1 = intra_value(x1, row_index, ...);
f2 = intra_value(x2, row_index, ...);

while (fabs(upper_bound - lower_bound) > tolerance) {
    if (f2 > f1){
        upper_bound = x2; x2 = x1; f2 = f1;
        x1 = upper_bound - golden_ratio*(upper_bound - lower_bound);
        f1 = intra_value(x1, row_index, ...);
    } else {
        lower_bound = x1; x1 = x2; f1 = f2;
        x2 = lower_bound + golden_ratio*(upper_bound - lower_bound);
        f2 = intra_value(x2, row_index, ...);
    }
}
// Estimated minimizer = (lower bound + upper bound) / 2
*xmin = (lower_bound + upper_bound)/2;
fxmin = intra_value(*xmin, row_index, ...);
return - fxmin; }