Bug描述
在测量如下一个简单的核函数的执行时间的时候,发现测量的时间和循环的次数完全无关,觉得很奇怪,因为循环的次数已经很大了,不管我再怎么提升循环次数,这么大的计算量,不可能保持时间的恒定。
c
__global__ void setRowReadRow(int * out)
{
unsigned int idx=threadIdx.y*blockDim.x+threadIdx.x;
for(unsigned int l0=0; l0<65536; l0++)
for(unsigned int l1=0; l1<65536; l1++)
for(unsigned int l2=0; l2<65536; l2++)
for(unsigned int l3=0; l3<65536; l3++)
for(unsigned int m=0; m<65536; m++){
out[idx] += m ;
}
}
于是去查看该Kernel的PTX代码,发现该函数主体只有一条ret
指令,用于函数返回,没有任何计算过程:
.visible .entry setRowReadRow(int*)(
.param .u64 setRowReadRow(int*)_param_0
)
{
ret;
}
这就解释得通为什么执行时间不变了,于是尝试调小循环次数,只保留变量m
这一层嵌套,此时PTX代码如下:
.visible .entry setRowReadRow(int*)(
.param .u64 setRowReadRow(int*)_param_0
)
{
ld.param.u64 %rd1, [setRowReadRow(int*)_param_0];
cvta.to.global.u64 %rd2, %rd1;
mov.u32 %r1, %tid.y;
mov.u32 %r2, %ntid.x;
mov.u32 %r3, %tid.x;
mad.lo.s32 %r4, %r1, %r2, %r3;
mul.wide.u32 %rd3, %r4, 4;
add.s64 %rd4, %rd2, %rd3;
ld.global.u32 %r5, [%rd4];
add.s32 %r6, %r5, 2147450880;
st.global.u32 [%rd4], %r6;
ret;
}
这里不解释每条指令的具体含义了,可以用GPT等大模型帮忙翻译一下,重点解释这两条指令:
add.s32 %r6, %r5, 2147450880;
st.global.u32 [%rd4], %r6;
%r5
保存的是out[idx]的原始值,%rd4
保存的是out[idx]在内存中的地址,所以这两条指令的意思就是out[idx]加上2147450880的值再存回去。
因为这部分代码只保留了m
变量所在的那一层循环,分析可得,Kernel函数得到的结果就是把out[idx]的值再加上(0+1+2+3+...+65535)=2147450880。
很显然,编译器帮我们做了优化,把65536次循环加法变成了一次加法指令,再加上英伟达官方论坛的解答可以大致推测出,循环次数过多导致PTX代码只有一条ret
指令的原因是编译器在做优化时,把循环的加法拿出去计算,导致了溢出了所以产生了不可预期的错误。
但是测试的时候发现把加法改成乘法后不会产生ret
错误,分析ptx是因为对于乘法没有做这方面的优化,老老实实按照循环嵌套写的PTX代码,所以此时虽然out[idx]的计算会出现溢出,但是并不影响程序的运行。加法由于编译器会对循环优化,所以出现PTX的异常。