O3優化標誌使並行處理速度加快

我正在使用OpenMP測試C中並行程序的加速。使用-O3標誌來編譯帶有gcc的代碼，執行時間似乎要小得多。但是，與不帶優化標誌編譯的代碼相比，我一直對不同線程號（2,4,8,16,24）的加速速度較慢。這怎麼可能？O3優化標誌使並行處理速度加快

以下是關於迄今爲止發現的更多信息。我正在編寫一個用於根據Sieve of Eratosthenes查找素數的代碼，並嘗試使用OpenMP的並行版本對其進行優化。下面是代碼

#include <stdio.h> 
#include <stdlib.h> 
#include <omp.h> 
#include <math.h> 

// ind2num: returns the integer (3<=odd<=numMax) 
//  represented by index i at prime_numbers (0<=i<=maxInd) 
#define ind2num(i) (2*(i)+3) 
// num2ind: retorns the index (0<=i<=maxInd) at prime_numbers 
//  which represents the number (3<=odd<=numMax) 
#define num2ind(i) (((i)-3)/2) 

// Sieve: find all prime numbers until ind2num(maxInd) 
void Sieve(int *prime_numbers, long maxInd) { 
    long maxSqrt; 
    long baseInd; 
    long base; 
    long i; 

    // square root of the largest integer (largest possible prime factor) 
    maxSqrt = (long) sqrt((long) ind2num(maxInd)); 

    // first base 
    baseInd=0; 
    base=3; 

    do { 
     // marks as non-prime all multiples of base starting at base^2 
     #pragma omp parallel for schedule (static) 
     for (i=num2ind(base*base); i<=maxInd; i+=base) { 
      prime_numbers[i]=0; 
     } 

     // updates base to next prime number 
     for (baseInd=baseInd+1; baseInd<=maxInd; baseInd++) 
      if (primos[baseInd]) { 
       base = ind2num(baseInd); 
       break; 
      } 
    } 
    while (baseInd <= maxInd && base <= maxSqrt); 

}

如果我執行它找到所有素數小於十億（10^9），例如，我結束了以下執行時間不同數量的線程（1,2， 4,8,16,24）：

Without -O3 | 56.31s | 28.87s | 21.77s | 11.19s | 6.13s | 4.50s |

With -O3 .... | 10.10s | 5.23s | 3.74s | 2.81s | 2.62s | 2.52s |

這裏有相應的速度起坐：

沒有-O3 | 1 | 1.95 | 2.59 | 5.03 | 9.19 | 12.51 |

With -O3 .... | 1 | 1.93 | 2.70 | 3.59 | 3.85 | 4.01 |

我怎麼一直在用-O3旗子降低速度？

來源

2016-08-19 Gabriel Ilharco

@ user3386109，他正在平行化篩選給定素數的倍數的過程（查找#pragma omp）。 –

你如何計算時間和數字代表什麼（例如'clock_gettime'的差異）？它看起來像（例如）爲24，沒有「-O3」是4.5s，並且是2.52s（即_with_是~2x更快）。你是否證實所有線程的_results_都是相同的？也就是說，在修改'primos'時沒有競爭條件。另外，除了〜4個線程，你可以通過訪問'primos'來飽和內存總線，這是限制因素，無論內核的數量如何。 –

對於每個線程數，「-O3」優化代碼的運行時間低於默認優化代碼的運行時間。這就是你應該看的。沒有理由認爲，增加threadcount的加速比例應該與其他例子相同 - 比較*不同程序*的加速比例。 –

算法的執行將需要一定量的內存帶寬。代碼優化程度越低，內部CPU機器人在運行時間中占主導地位。代碼越優化，運行時間越佔用內存速度。

由於未優化的代碼效率較低，因此在系統內存帶寬飽和之前，有更多的內核可以運行它。由於優化後的代碼效率更高，因此可以更快地完成內存訪問，從而增加系統內存帶寬的負擔。這使得它不太可並行化。

來源

2016-08-19 18:51:47

我寧可說，在這種特殊情況下，可擴展性受OpenMP開銷和僅部分代碼並行（Amdahl定律）這一事實的限制。沒有優化的編譯會增加並行時間，從而降低開銷+串行部分的百分比。 –

O3優化標誌使並行處理速度加快

回答

相關問題