# A03: compute-pi
如果你真的忘記微積分,趕快透過均一教育平臺學習「微積分概論」。
N 越大(切的越細),數值越精確。
double computePi_v1(size_t N)
{
double pi = 0.0;
double dt = 1.0 / N; // dt = (b-a)/N, b = 1, a = 0
for (size_t i = 0; i < N; i++) {
double x = (double) i / N; // x = ti = a+(b-a)*i/N = i/N
pi += dt / (1.0 + x * x); // integrate 1/(1+x^2), i = 0....N
}
return pi * 4.0;
}
AVX (Advanced Vector Extensions) 是 Intel 一套用來作 Single Instruction Multiple Data 的指令集
$ cat /proc/cpuinfo | grep flags
尋找是否存在 fma
關鍵字Intel(R) Core(TM) i5-3317U CPU
等級的電腦就沒支援,這樣的話可用模擬器__m256d
並不是一種暫存器,是指可以用來載入到 AVX 暫存器的 "Data type"
後面程式中用到了__attribute__
機制,可以用來設置函數屬性(Function Attribute)、變數屬性(Variable Attribute)和類型屬性(Type Attribute)。aligned
則規定變數或結構的最小對齊格式,以 Byte 為單位。
source 為何 AVX SIMD 的版本沒辦法達到預期 4x 效能提昇呢?
因為浮點 scalar 除法和 vector 除法的延遲,導致沒辦法有效率的執行。考慮到填充 vector instruction 的 pipeline 未能充分使用,我們可以預先展開迴圈,以便使用更多的 scalar 暫存器,從而減少資料相依性。
for (int i = 0; i <= dt - 4; i += 4) {
ymm3 = _mm256_set1_pd(i * delta);
ymm3 = _mm256_add_pd(ymm3, ymm2);
ymm3 = _mm256_mul_pd(ymm3, ymm3);
ymm3 = _mm256_add_pd(ymm0, ymm3);
ymm3 = _mm256_div_pd(ymm1, ymm3);
ymm4 = _mm256_add_pd(ymm4, ymm3);
}
可以看到 ymm3 有很強的相依性,而且看起來無法在縮得更小了。
嘗試使用更多的 AVX 暫存器來作 unroll looping 的優化,從原本的 ymm0~ymm4,增加到 ymm0~ymm14。但這種寫法的缺點就是程式碼遍得很龐大,而且不易閱讀。實驗結果在最下面。
除了AVX SIMD 版本外,也使用 OpenMP 對的 for 迴圈作平行處理,而為了使編譯器能後成功的將順序執行轉為平行執行,運行系統必須確定循環的次數,因此 for 迴圈內不可以包含讓迴圈提前退出的關鍵字,例如 break、return、exit、goto,不過允許 continue 的存在。
以下是 openmp 語法,大概長這樣。詳情可參閱最後面的參考資料
#pragma omp <directive> [clause]
對於簡單的 for 迴圈的平行處理例子:
#pragma omp parallel for
for (int i = 0; i < 10; ++i)
test(i);
不過因為這個式子pi += dt / (1.0 + x * x);
的存在,每次迭代都會讀取 pi 值並更新 pi 值,不同次的迴圈中並不相互獨立。因此不能簡單加上#pragma omp parallel for
就好,還要作些處理。
reduction(<op>:<variable>)
支援的運算元有 +, , –, &, ^, |, &&, ||,它讓各個執行緒針對指定的變數擁有一份有起始值的複本(起始值是運算元而定,像 +, – 的話就是 0, 就是 1),平行化計算時,以各自複本做運算,等到最後再以指定的運算元,將各執行緒的複本合在一起。
#pragma omp parallel num_threads(omp_get_max_threads())
{
#pragma omp for private(x) reduction(+:pi)
for (size_t i = 0; i < N; i++) {
x = (double) i / N;
pi += dt / (1.0 + x * x);
}
return pi * 4.0;
}
注意 Makefile
裡頭有 -fopenmp -mavx
,指定開啟 OpenMP 和 AVX
CFLAGS = -O0 -std=gnu99 -Wall -fopenmp -mavx
取得原始程式碼並編譯:
$ git clone https://github.com/sysprog21/compute-pi
$ cd compute-pi
$ make check
$ make gencsv
之後可用 LibreOffice 建立圖表,如下所示:
兩種不同的測量時間的函式,一個是 clock()
,另一個則是 clock_gettime()
,而在圖表上也呈現了兩種截然不同的結果。
進入實驗討論前,先了解一下時間觀念和如何使用 C 語言進行時間處理。畢竟要作 Performance Benchmarking,沒有正確使用 time 函式,可能就會導致錯誤的結果和結論。
撰寫時間量測程式前,先評估情況,問問自己幾個問題:
通常我們在計算一個程序的 "Duration time",常常有可能是以下兩個意思,一個是「Wall-clock time」,另一個則是 「CPU time」,根據不同的情況和需求來選擇使用哪一個當作衡量標準。
1. Wall-clock time 顧名思義就是掛鐘時間,也就是現實世界中實際經過的時間,是由 kernel 裡的 xtime 來紀錄,系統每次啟動時會先從設備上的 RTC 上讀入 xtime。
struct timespec xtime __attribute__ ((aligned (16)));
struct timespec {
__kernel_time_t tv_sec; /* seconds */
long tv_nsec; /* nanoseconds */
};
這個值是自 1970-01-01 起經歷的秒數,另外 Linux 核心也會決定每秒要發生幾次中斷 (透過常數 HZ) ,每次 timer interrupt,就會去更新 xtime
。
許多說明文件或問答網站常將 System time 和真實世界的 Wall-clock time 混用,System time 是指系統上的時間,開機時它會讀取 RTC 來設定,可能過程中還會有時區換算等之類的設置。一般說來 System time 就是我們執行 date
命令看到的時間,Linux 系統下所有的時間調用都是使用這個 (除非直接存取 RTC)。然後 Kernel 會有個全域變數 Jiffies 來紀錄系統開幾以來,經過多少個 tick。每發生一次 timer interrupt,jiffies 會加 1 ( xtime 和 jiffies 很相似,但其實完全不一樣,可參閱 容易混淆 LINUX 時鐘的 xtime 和 jiffies )。
另外注意,有時系統要與網絡中某個節點時間同步,那這個 Wall-clock time 可能會和 NTP 伺服器、時區、日光節約時間同步或使用者自己調整。所以「通常」不建議拿來量測程式時間,因為它不是一個穩定的時間,用專業一點的用語講,Wall-clock time 不一定是單調遞增 (monotonic)。
不過在這裡因為量測過程中沒有涉及到 NTP、時區改變之類的問題,Wall-clock time 是單調遞增,所以在電腦上所經過的 system time (elapsed time) 基本上會等於真實走過的時間。
2. CPU time 指的是程序在 CPU 上面運行消耗 (佔用) 的時間,clock() 就是很典型用來計算 CPU time 的時間函式,但要注意的是,如果有多條 threads,那 CPU time 算的是「每條 thread 的使用時間加總」,所以如果我們發現 CPU time 竟然比 Wall-clock time 還大!這可能是個很重要的原因。
另外很多時候只計算 CPU time 是不夠的,因為執行時間可能還包括 I/O time、 communication channel delay、synchronization overhead....等等。
在今日的 UNIX 系統內事實上存在兩個 time 指令,一個是系統所提供的 /usr/bin/time,這個 time 指令是 System V 版本所提供的工具,這是為了 Bourne shell 使用者所寫的工具;而另一個則是 C shell 內建指令 time。
$ time
會報告實際時間,也就是程式從開始到結束的經歷時間,另外還會計算程式使用處理器時間量。
在單一處理器的情況下,可以使用 real - (user + sys)
來計算 Wall-clock time 與 CPU time 的差異。可以理解「所有」可以延遲程式的因子的總和。在 SMP 底下可以近似成 (real * 處理器數目) - (user + sys)
。而這些因子可能是:
所謂 CPU bound,指的是程序需要大量的 CPU computation (對 CPU time 需求量大),相比之下僅需少量的 I/O operation,效能取決於 CPU 速度。
所謂 I/O bound,需要大量 I/O operation (I/O request 的頻率很高或一次 I/O request 成本很高),但僅需少量的 CPU computation,效能取決於 I/O device 速度。
很多時候我們可以使用 time 判斷程式是 CPU bound 還是 I/O bound。
real < user
: 表示程式是 CPU bound,使用平行處理有得到好處,效能有提昇。real ≒ user
: 表示程式是 CPU bound,即使使用平行處理,效能也沒有明顯提昇,常見的原因有可能是其實計算量沒有很大,生成、處理、結束多執行緒的 overhead 吃掉所有平行處理的好處,或是程式相依性太高,不適合拿來作平行處理。real > user
: 表示程式是 I/O bound,成本大部分為 I/O操作,使得平行處理無法帶來顯著的效能提昇 ( 或沒有提昇)。延伸思考:
$ make gencsv
以外的輸出機制,預期執行 $ make plot
後,可透過 gnuplot 產生前述多種實做的效能分析比較圖表