作者a34021501 (CARD)
看板C_and_CPP
標題[討論] 浮點數運算的效能與誤差
時間Sun Oct 8 04:12:53 2017
各位好
各種不同 GPGPU 與 CPU 之間的浮點數運算
擁有很多不同的方式可以計算出不同精確度
例如 PhenomII 時代的 GPU 就已經是 GPGPU
可以透過 OpenCL 將大量 MIMD 交給 GPGPU
因此有些浮點數運算會 offload 到 GPGPU
一直以來不同 Device 有不同的浮點數誤差
但近期發現同 Device 多次運算卻不同結果
其實我只是想要寫個 GPGPU Benchmark 程式
http://cargon.net/GMEMD/GMEMD_GPU_Color_Real16bit_Benchmark.7z
但我發現每次交給 OpenCL 運算後有時出錯
也有可能是匯流排傳輸時發生錯誤導致誤差
因此我在比較的時候還重複比較反覆確認之
token=0;
for(int j=0;j<t_height;++j){
for(int i=0;i<t_width;++i){
if( !( cvGetReal2D(fimg2_ch[0],j,i) == cvGetReal2D(fimg2_ch[1],j,i) &&
cvGetReal2D(fimg2_ch[2],j,i) == cvGetReal2D(fimg2_ch[0],j,i) &&
cvGetReal2D(fimg2_ch[1],j,i) == cvGetReal2D(fimg2_ch[2],j,i) )
) token=1;
if( !( cvGetReal2D(fimg2_ch[2],j,i) == cvGetReal2D(fimg2_ch[1],j,i) &&
cvGetReal2D(fimg2_ch[0],j,i) == cvGetReal2D(fimg2_ch[2],j,i) &&
cvGetReal2D(fimg2_ch[1],j,i) == cvGetReal2D(fimg2_ch[0],j,i) )
) token=1;
if( !( cvGetReal2D(fimg2_ch[1],j,i) == cvGetReal2D(fimg2_ch[2],j,i) &&
cvGetReal2D(fimg2_ch[2],j,i) == cvGetReal2D(fimg2_ch[0],j,i) &&
cvGetReal2D(fimg2_ch[0],j,i) == cvGetReal2D(fimg2_ch[1],j,i) )
) token=1;
}
}
printf("token=%d ",token);
因為輸入的影像是 Grayscale 所以在重複執行 OpenCL Kernel 三次的數值應該完全相同
但有時候 token 還是會被寫入 1，即代表 3 次相同浮點數運算有不同結果於記憶體存取
不知道大家看法如何？
這問題困擾了我很久！
--
※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 36.229.44.220
※ 文章網址: https://webptt.com/m.aspx?n=bbs/C_and_CPP/M.1507407177.A.D71.html
※ 編輯: a34021501 (36.229.44.220), 10/08/2017 04:16:10
1F：推 Ommm5566: semaphore mutex atomic 自己選一個 10/08 04:29
2F：→ longlongint: 同一行為什麼要跑三次 10/08 10:34
3F：推 Killercat: 你先確認一下token寫入時的值 10/08 15:38
4F：推 LPH66: OpenCL 的同步是使用 barrier() 去研讀那部份的東西 10/08 18:04
5F：→ LPH66: 簡單的觀念是不經過 barrier() 不該去撈別人負責的格子 10/08 18:05
6F：→ Killercat: barrier主要是擋CPU亂序，GPU....也能用嗎o_oa? 10/09 04:27
7F：推 LPH66: 呃嗯, 我其實不太確定這邊是在問 kernel 運算本身 10/09 09:32
8F：→ LPH66: 還是 host/device 的傳遞資料, 畢竟結果出錯的原因 10/09 09:33
9F：→ LPH66: 這兩者其中之一出錯都有可能 10/09 09:33
10F：→ LPH66: 我提的 barrier() 是 kernel code 裡的東西 10/09 09:33
11F：→ LPH66: 主要是同一 Workgroup 內的各 Workitem 之間同步 10/09 09:33
12F：→ LPH66: 這只單純是在講 device 端的 kernel 運算 10/09 09:34
13F：推 Bencrie: a34 發文其實不用太認真看就是 XD 10/09 13:26
14F：→ liflguy: 看到GPU OPENCL猜ID 10/09 18:19
15F：→ a34021501: 其實 barrier 只在 GPGPU 中的某個 module 中等待同步! 10/09 22:38
16F：→ a34021501: 所以軟體的 Workgroup 如何分配到 module 會有效能差異 10/09 22:39
17F：→ a34021501: 其實這支程式在測試的時候發生不同步才會分兩階段Event 10/09 22:40
18F：→ a34021501: 即等待 kernel function 結束才 read 或 next function 10/09 22:45
19F：→ a34021501: 而這個測試採用的是太陽系內某些磁場的空間頻率分佈圖! 10/10 15:34
20F：→ a34021501: 因此如果磁場在waffer上的頻率不太正常的話可能會出錯! 10/10 15:35
21F：→ a34021501: 因為在 EnqueueBuffer 的時候會將整個影像以 bus 寬度~ 10/10 15:36
22F：→ a34021501: 傳送進 GPGPU 的 GlobalMemory (GDDR) 產生相應電磁波! 10/10 15:37
23F：→ a34021501: 所以太陽系內如果磁場不太正常，就可能發生些許的錯誤~ 10/10 15:38
24F：推 Hazukashiine: 哇嗚嗚新發現耶 快發paper!!!! 10/10 15:38
25F：→ Hazukashiine: IEEE Trans on Electromagnetic Compatibility 等你 10/10 15:39
26F：→ a34021501: 但是螢幕只有 16bit 色深的話其實根本看不出來錯在哪裡 10/10 15:39
27F：推 Hazukashiine: 你有紙筆對吧 算一下能量夠不夠啊 實驗做一下 10/10 15:42
28F：→ Hazukashiine: 我有認識這領域的 IEEE Editor 要不要幫你呢～嘻嘻 10/10 15:44
29F：→ a34021501: 最近鐘擺都會被重力電磁場推動而產生非常不穩態的計時! 10/10 15:44
30F：→ Hazukashiine: 而且貴先生應該對這個領域很有研究 還發了很多篇呢 10/10 15:44
31F：→ Hazukashiine: 不止在我們版上發 還發到被水桶十年真是功績斐然 10/10 15:45
32F：→ Hazukashiine: 鐘擺哈哈鐘擺 你知道現在都用原子鐘嗎哈哈哈哈哈哈 10/10 15:46
33F：→ Hazukashiine: 原子鐘用能階釋放的微波訊號計時 會不會也有影響呢 10/10 15:50
34F：→ a34021501: 不同計時器要確保每次同步累加避免對時錯誤而傳輸異常! 10/10 15:50
35F：→ a34021501: 但也有可能是衛星或其他裝置使用超過IEEE的電磁規範... 10/10 17:36
36F：→ MOONRAKER: 難怪有不太舒服的熟悉感 :| 10/16 19:21
37F：推 CoNsTaR: 竟然鬧到這裡來了 = = 10/16 23:45
38F：→ kingofsdtw: 壓力大概很大? 10/17 19:53
39F：→ CP64: 已經不只是壓力大的程度了吧..... 10/17 21:31
40F：→ narcissusli: 我好像迷路了,這裡是Gundam版嗎...??? 10/17 21:49
41F：→ ssdoz2sk: 他到底要被多少個版水桶才不會發奇怪的文章阿 10/17 23:28