编译器优化：g比intel慢-Java 学习之路

我最近购买了一台带有双启动的计算机，以C语言编写代码 . 在Windows上我在linux上使用intel C编译器和g . 我的程序主要包括计算（具有数值积分的定点迭代算法等） .
我以为我可以在linux上接近windows的表演，但到目前为止我还没有：对于完全相同的代码，用g编译的程序比用intel编译器慢大约2倍 . 从我读到的内容来看，icc可以更快，甚至可以达到20-30％的增益，但我没有读到关于它的速度提高两倍的任何信息（总的来说，我实际上读到两者都应该是等价的） .

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

icl / openmp / I“C：\ boost_1_61_0”/ fast program.cpp

和

g -o program program.cpp -std = c 11 -fopenmp -O3 -ffast-math

根据其他几个主题的建议，我尝试添加/替换其他几个标志，如： - funsafe-math-optimizations，-march = native，-fwhole-program，-Ofast等，只有轻微（或没有）性能增益 .

icc真的更快还是我错过了什么？我知道，也许我忘记安装正确的东西（如驱动程序），或改变g中的某些选项？我不知道情况是否正常，这就是我更喜欢问的原因 . 特别是因为我更喜欢使用linux进行理想的编码，所以我宁愿让它达到速度 .

EDIT: 我决定在linux上安装最后一个intel编译器（Intel Compiler C 17，update4）来检查 . 我最终得到了缓解的结果：它并不比gcc做得更好（事实上甚至更糟） . 我运行交叉比较linux / windows - icc / gcc - 并行或没有，使用前面提到的标志（进行直接比较），这是我的结果（以ms为单位运行1次迭代的时间）：

普通循环，没有并行化：
Windows：
gcc = 122074; icc = 68799
Linux：
gcc = _91042; icc = 92102
并行化版本：
Windows：
gcc = 27457; icc = 19800
Linux：
gcc = 27000; icc = 30000

总结一下：这有点乱 . 在linux上，gcc似乎总是比icc更快，特别是当涉及并行化时（我运行它用于更长的程序，差异远远高于此处的那个） .
在Windows上，它是相反的，icc显然支配gcc，特别是当没有并行化时（在这种情况下gcc需要很长时间才能编译） .

最快的编译是通过Windows上的并行化和icc完成的 . 我不明白为什么我不能在linux上复制这个 . 有什么我需要做的（ubuntu 16.04）来帮助加固我的流程吗？
另一个区别是，在Windows上，我使用较旧的英特尔作曲家（ Composer XE 2013 ）并调用'ia32 ' instead of intel64 (which is the one I should be using) while on linux I use the last version that I installed yesterday. And on linux, the Intel Compiler 17 folder is on my second hdd (and not my ssd on which linux is install) I don' t知道这是否会减慢速度 .
知道问题可能来自哪里？

Edit: 精确硬件：Intel（R）Core（TM）i7-4710HQ CPU @ 2.50GHz，8个CPU，4个内核，每个内核2个线程，架构x86_64 - 带有gcc 5.4.1的Linux Ubuntu 16.04和Intel编译器17（update4） - Windows 8.1，Intel Composer 2013

Edit: 代码很长，这里是循环的形式，我认为非常经典...不确定它可以为主题带来什么 .

// 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

其中V_compute函数是一个经典而简单的优化算法（自定义黄金搜索），返回最佳值及其参数：

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; }

优化的函数（intra_value）在计算方面非常复杂（从预编译网格中选择网格点（row_index），然后涉及大量数值积分等） .

2 回答

12

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

众所周知，英特尔的OpenMP运行时具有相当高的性能，GCC虽然好但不是很好 .

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

回复于 2023-12-03T15:11:40+08:00
20

请注意，“fast-math”会破坏某些语言规则以获取快速代码，并且在某些情况下可能会产生不正确的结果 .

另请注意， -O3 不能保证比 -O2 或任何其他优化级别更快（取决于您的代码） - 您应该测试多个版本 .

您可能还想启用 -Wl,-O1 - 链接器也可以进行一些优化 .

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

我意识到这不能回答你的问题 . 但它应该给你一些东西:-)

此外，gcc正在快速提升 . 如果您尚未使用7.1，则可能需要尝试更新的版本 . 也;尝试Clang获得第三个数据点 . 此外，如果您愿意，可以在Linux上使用icc .

回复于 2023-12-03T15:11:40+08:00

编译器优化：g比intel慢

2 回答

相关问题