[討論] 浮點數運算的效能與誤差

作者: a34021501 (CARD)   2017-10-08 04:12:53
各位好
各種不同 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 次相同浮點數運算有不同結果於記憶體存取
不知道大家看法如何?
這問題困擾了我很久!
作者: Ommm5566 (56天團)   2017-10-08 04:29:00
semaphore mutex atomic 自己選一個
作者: longlongint (華哥爾)   2017-10-08 10:34:00
同一行為什麼要跑三次
作者: Killercat (殺人貓™)   2017-10-08 15:38:00
你先確認一下token寫入時的值
作者: LPH66 (-6.2598534e+18f)   2017-10-08 18:04:00
OpenCL 的同步是使用 barrier() 去研讀那部份的東西簡單的觀念是不經過 barrier() 不該去撈別人負責的格子
作者: Killercat (殺人貓™)   2017-10-09 04:27:00
barrier主要是擋CPU亂序,GPU....也能用嗎o_oa?
作者: LPH66 (-6.2598534e+18f)   2017-10-09 09:32:00
呃嗯, 我其實不太確定這邊是在問 kernel 運算本身還是 host/device 的傳遞資料, 畢竟結果出錯的原因這兩者其中之一出錯都有可能我提的 barrier() 是 kernel code 裡的東西主要是同一 Workgroup 內的各 Workitem 之間同步這只單純是在講 device 端的 kernel 運算
作者: Bencrie   2017-10-09 13:26:00
a34 發文其實不用太認真看就是 XD
作者: liflguy (xxxwino)   2017-10-09 18:19:00
看到GPU OPENCL猜ID
作者: a34021501 (CARD)   2017-10-09 22:38:00
其實 barrier 只在 GPGPU 中的某個 module 中等待同步!所以軟體的 Workgroup 如何分配到 module 會有效能差異其實這支程式在測試的時候發生不同步才會分兩階段Event即等待 kernel function 結束才 read 或 next function
作者: Hazukashiine (私は幸せです)   2017-10-10 15:38:00
哇嗚嗚新發現耶 快發paper!!!!IEEE Trans on Electromagnetic Compatibility 等你
作者: a34021501 (CARD)   2017-10-10 15:39:00
但是螢幕只有 16bit 色深的話其實根本看不出來錯在哪裡
作者: Hazukashiine (私は幸せです)   2017-10-10 15:42:00
你有紙筆對吧 算一下能量夠不夠啊 實驗做一下我有認識這領域的 IEEE Editor 要不要幫你呢~嘻嘻
作者: a34021501 (CARD)   2017-10-10 15:44:00
最近鐘擺都會被重力電磁場推動而產生非常不穩態的計時!
作者: Hazukashiine (私は幸せです)   2017-10-10 15:44:00
而且貴先生應該對這個領域很有研究 還發了很多篇呢不止在我們版上發 還發到被水桶十年真是功績斐然鐘擺哈哈鐘擺 你知道現在都用原子鐘嗎哈哈哈哈哈哈原子鐘用能階釋放的微波訊號計時 會不會也有影響呢
作者: a34021501 (CARD)   2017-10-10 15:50:00
不同計時器要確保每次同步累加避免對時錯誤而傳輸異常!但也有可能是衛星或其他裝置使用超過IEEE的電磁規範...
作者: MOONRAKER (㊣牛鶴鰻毛人)   2017-10-16 19:21:00
難怪有不太舒服的熟悉感 :|
作者: CoNsTaR ((const *))   2017-10-16 23:45:00
竟然鬧到這裡來了 = =
作者: kingofsdtw (不能閒下來!!)   2017-10-17 19:53:00
壓力大概很大?
作者: CP64 (( ̄▽ ̄#)﹏﹏)   2017-10-17 21:31:00
已經不只是壓力大的程度了吧.....
作者: narcissusli   2017-10-17 21:49:00
我好像迷路了,這裡是Gundam版嗎...???
作者: ssdoz2sk (眷戀著提拉米蘇的風采~)   2017-10-17 23:28:00
他到底要被多少個版水桶才不會發奇怪的文章阿

Links booklink

Contact Us: admin [ a t ] ucptt.com