1

我试图围绕最有效的方法来处理不确定大小的数组作为 RS 内核的输出。我会在 out 分配中发送最后一个相关数组槽的索引，但我在对上一个问题的回答中了解到，在内核执行后将全局返回给 java 并不是一个好方法。我决定再次“缩小”这个过程，这让我看到了下面的模式。

例如，假设我们有一个输入分配，其中包含一个结构（或多个结构），该结构包含两个极坐标数组；类似于下面的 set_pair ：

typedef struct polar_tag{
  uint8_t angle;
  uint32_t mag;
} polar;

typedef struct polar_set_tag{
  uint8_t filled_slots;
  polar coordinates[60];
} polar_set;

typedef struct set_pair_tag{
  polar_set probe_set;
  polar_set candidate_set;
} set_pair;

我们希望在集合之间找到相似的坐标对，因此我们设置了一个内核来确定哪些（如果有的话）极坐标是相似的。如果它们相似，我们将其加载到类似于“matching_set”的输出分配中：

typedef struct matching_pair_tag{
  uint8_t probe_index;
  uint8_t candidate_index;
} matching_pair;

typedef struct matching_set_tag{
  matching_pair pairs[120];
  uint8_t filled_slots;
} matching_set;

使用诸如“filled_slots”之类的指令创建分配是使用 RS 处理这种不确定 I/O 的最有效（或唯一）方法，还是有更好的方法？

4

1 回答 1

2

我认为我尝试解决此问题的方法是通过两次。

对于 0-2 情况：

设置：对于每个坐标，分配一个数组来保存最大预期对数 (2)。

Pass 1：遍历坐标，通过将当前项目与其他坐标的子集进行比较来查找对。当内核在被比较的另一个坐标上运行时，选择子集以避免重复答案。

第 2 步：将 #1 的结果合并回列表或您想要的任何其他数据结构。如果坐标数量很少，则可以作为可调用对象运行。

对于 0-N 情况：

这变得更加困难。我可能会做与上面类似的事情，但每个坐标数组的大小适合典型的对数。对于（希望很小）数量的溢出，使用原子在溢出缓冲区中保留一个插槽。这里的问题是我认为大多数 GPU 驱动程序对今天的原子操作并不满意。在 CPU ref 上运行得很好。

有很多方法可以解决这个问题。一个重要的决策点围绕着比较找到点的成本与编写结果的成本。

于 2013-10-23T21:04:06.680 回答