Memory 为什么OpenCL内核中的死代码会影响Nvidia GTX550ti？

我在GTX550ti图形卡上使用Nvidia的OpenCL开发软件，遇到了一个奇怪的问题。（我是OpenCL的大一新生）

我的内核代码如下：

__kernel void kernel_name(...)
{
size_t d = get_local_id(0);
char abc[8];
...
}

事实上，

charabc[8]

对我来说是无用的（死代码）。但是，如果在我的内核代码中有

charabc[8]

，结果将非常混乱，内核的运行时间将更长（2095712ns）。如果我注释掉

字符abc[8]

，结果就会正确，内核的运行时间也会缩短（697856 ns）。内核的编译器不会清除死代码吗

以上只是一个明确的例子，我可以重复。我还遇到了更奇怪的情况，一个程序在完全相同的环境中在不同的时间运行时会得到不同的结果

这与内存分配或..有关吗。。？谁能给我一些关于如何发现问题的建议

顺便说一下，OCLDevicequiry输出信息如下所示： 平台版本=OpenCL 1.1
CUDA 4.2.1，
SDK修订版=7027912

我的操作系统是Windows XP

今天是2012-07-17，我想我已经解决了这个问题

不要在内核源文件中使用#include

不要在内核源文件中使用超长行（例如，您编写程序为内核源文件生成一些行数据）

---

你说得对，那不会有任何影响

不过，这不是您真正的代码，我怀疑在这些运行时，您的内核并不是一件简单的事情。可能您正在将局部变量推到某个极限之上，这意味着变量必须存储在某个较慢的内存中，从而推高运行时间

如果您在某个地方有一个未初始化的变量bug，那么类似的事情也可能会导致行为的改变。在fast store中，它碰巧得到了一个有效的值。在慢行商店里，它可以买到别的东西

为了验证这一理论，我尝试删除一些其他本地数据结构，看看它是否具有相同的效果。任何其他8字节或更大的内容都应该具有相同的效果

---

…当然，您可能在OpenCL实现中发现了一个bug，但这很容易检查。只需为不同的OpenCL设备编译内核，例如CPU。无论如何，这是值得做的，因为不同的编译器会发现不同的问题

除此之外，我认为您回到了标准调试技术

---

---

顺便说一句：在你问题的某一点上，你调用数组

abs[8]

，而不是

abc[8]

。我认为这是一个输入错误，但如果不是，那可能是您的问题，因为

abs

名称将与

abs（）

函数冲突。这可能会把一个愚蠢的编译器弄糊涂。

谢谢。事实上，我的代码在使用intel和AMD OpenCL SDK的CPU上正确运行。顺便说一句，我使用的是abc[8]，而不是abs[8]（你可以仔细检查我的问题）。没有输入错误。您写道：“如果我注释掉“char abs[8]”，结果就会正确，”。我刚刚编辑了它来纠正它。哦，真的。我很抱歉。这是一个打字错误。在我的真实代码中，它是abc[8]。无论如何，这很奇怪。我做了更多的实验，我认为问题可能与如何将内核文件读取为字符串以及clCreateProgramWithSource如何处理字符串有关。我将尝试使用二维字符串而不是当前的一维字符串来表示内核源代码。但问题仍然存在。现在，我和我的同事倾向于认为问题与屏障位置和并行执行的固有特性（同步、锁定、一致等）有关。在我的代码中，对同步必须有一些松散的约束，并且每次执行都会导致不同的结果。这取决于操作系统/计算机环境的某些运行时情况。