爲什麼CILK_NWORKERS隻影響一個cilk_spawn程序？

Question

我正在嘗試將矩陣處理程序並列。使用OpenMP後，我決定還檢查了CilkPlus，我注意到以下幾點：

在我的C代碼，我只在一個部分，即適用於並行：

//(test_function declarations) 

cilk_spawn highPrep(d, x, half); 

d = temp_0; 
r = malloc(sizeof(int)*(half)); 
temp_1 = r; 
x = x_alloc + F_EXTPAD; 
lowPrep(r, d, x, half); 

cilk_sync; 

//test_function return 

根據該文件至今我已閱讀，希望cilk_spawn -maybe-（CilkPlus不強制並行性）採用highPrep（）函數，並在一個可用的硬件線程中執行它，然後繼續執行其餘代碼，包括函數lowPrep（）。然後線程應該在cilk_sync中同步，然後執行其餘的代碼。

我在8core/16thread Xeon E5-2680上運行該程序，除了我的實驗外，它在任何給定時間都不執行任何其他操作。我現在的問題是，我注意到當我更改環境變量CILK_NWORKERS並嘗試諸如2,4,8,16等值時，test_function需要執行的時間隨着變化而變化。特別是，CILK_NWORKERS設置得越高（2之後），函數變得越慢。這似乎對我來說很直觀，因爲我期望可用的線程數量不會改變cilk_spawn的操作。我期望如果2個線程可用，那麼函數highPrep在另一個線程上執行。任何超過2個線程，我預計會保持閒置。

的highPrep和lowPrep功能是：

void lowPrep(int *dest, int *src1, int *src2, int size) 
{ 
    double temp; 
    int i; 
    for(i = 0; i < size; i++) 
    { 
     temp = -.25 * (src1[i] + src1[i + 1]) + .5; 
     if (temp > 0) 
     temp = (int)temp; 
     else 
     { 
      if (temp != (int)temp) 
       temp = (int)(temp - 1); 
     } 
     dest[i] = src2[2*i] - (int)(temp); 
    } 
} 

void highPrep(int *dest, int *src, int size) 
{ 
    double temp; 
    int i; 
    for(i=0; i < size + 1; i++) 
    { 
     temp = (-1.0/16 * (src[-4 + 2*i] + src[2 + 2*i]) + 9.0/16 * (src[-2 + 2*i] + src[0 + 2*i]) + 0.5); 
     if (temp > 0) 
      temp = (int)temp; 
     else 
     { 
     if (temp != (int)temp) 
       temp = (int)(temp - 1); 
     } 
     dest[i] = src[-1 + 2*i] - (int)temp; 
    } 
} 

必須有這背後一個合理的解釋，這是合理的預期不同的執行時間這樣的計劃？

Answer 1

說明：Cilk做的是「繼續偷竊」，而不是「偷竊兒童」，所以highPrep總是在與其調用者相同的硬件線程上運行。這是「代碼的其餘部分」，可能最終在不同的線程上運行。請參閱this primer以獲得更全面的解釋。

至於放緩，它可能是一個人工因素的執行偏向高並行度，可能會消耗所有線程。額外的線程正在尋找工作，並在這樣做的過程中，吃掉一些內存帶寬，並且超線程處理器吃掉了一些核心週期。 Linux「完全公平的調度程序」給了我們一些這方面的痛苦，因爲睡眠（0）不再放棄時間片。額外的線程也可能導致操作系統將軟件線程低效地映射到機器上。

問題的根源是一個棘手的折衷：盜賊積極地使他們能夠更快地工作，如果沒有工作，他們也會不必要地消耗資源。在沒有可用工作的情況下讓盜賊進入休眠狀態可以節省資源，但是會增加產卵的重要開銷，因爲現在產卵線程必須檢查是否有睡眠線程被喚醒。 TBB支付這種開銷，但TBB並不多，因爲無論如何，TBB的產卵費用要高得多。目前的Cilk實施確實支付了這種稅：它只在順序執行期間讓工人休眠。

我可以給出的最好（但不完美）的建議是找到更多的並行性，這樣就不會有工作線程閒置很長時間並造成麻煩。