CUDA:thrust::sort_by_key 在内核中不起作用，但 thrust::sort 可以

Question

我正在尝试将一些现有的thrust::sort_by_key调用移动到内核线程。这些是大量的小排序 - 因此运行顺序排序的大量线程很有意义。

thrust::sort在内核中似乎工作正常，例如：(xp 是一个浮点数*;beg & en 是整数索引(

thrust::sort( thrust::seq, xp+beg, xp+en);

在我的主机端代码上，我使用的是thrust::zip_iterator。将其移植到内核似乎不起作用，所以我尝试创建自己的索引数组：

int*pIDX = new int[en-beg]; // inefficient: eventually this would be a global workspace
for (int i=0; i<en-beg; i++)
pIDX[i] = i;
thrust::sort_by_key( thrust::seq, xp+beg, xp+en, pIDX);

尝试此操作会在下一次 cudaMemCpy 调用时产生"未指定的启动失败 (719("。 使用调试器进行跟踪会导致在thrust::sort_by_key处终止，但没有消息。

搜索网络和这个站点建议sort_by_key如果我明确告诉它按顺序工作，它应该在内核中工作。那么关于可能出错的任何想法？

Answer 1

找到了解决方案。是的，这是一个堆问题，但不是在代码中的临时new中，而是在sort_by_key本身。扩展堆导致问题消失。出于某种原因sort不需要像sort_by_key那么多的堆。

我一时兴起尝试了zip_iterator，现在似乎也有效(抽象简化了我的代码！

对于这个测试，我在xp中使用了 9.7M 浮子。更广泛的问题有少量的大排序和大量的小排序 - 对于这个数据集，最大的排序是 9.7M，但它们可以一直下降到 2 个值。我已经 thrust 的并行排序工作正常，但这对于小排序来说效率太低了，所以计划是切换到我自己的内核 - 在并行线程上运行许多小排序。因此，一旦完全实现，应该可以再次减小堆大小。