作者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/cn.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