GPU上的线性排序。并行处理会改变 Big-O 吗？答案

【问题标题】：Linear sort on GPU. Does parallel processing change Big-O?GPU上的线性排序。并行处理会改变 Big-O 吗？
【发布时间】：2021-03-17 09:09:31
【问题描述】：

如果 GPU 真的能够并行计算代码。这个排序算法一定是正确的。

创建二维比较矩阵

O(n)

values = [ 3, 1, 2 ]

                     # 3  1  2
comparisonMatrix = [ [ 0, 1, 1 ], # 3
                     [ 0, 0, 0 ], # 1
                     [ 0, 1, 0 ]] # 2

# Done on GPU
comparisonMatrix[rowIdx][columnIdx] = values[rowIdx] > values[columnIdx]

计算行总和

O(n)

rowSums = [[ 1 ], # 3
           [ 0 ], # 1
           [ 2 ]] # 2

# Done on GPU
rowSums[rowIds] = comparisonMatrix[rowsIds][all]

使用 rowSums 数组作为索引将初始 values 映射到 sortedArray

O(1)

sortedValues = [ 1, 2, 3 ]

# Done on GPU
sortedValues[rowIdx] = values[rowSums[rowIdx]]

总计：O(n + n + 1) = O(n)

反论点：

GPU 的核心数量有限，因此迭代数组的大 O 是 O(n/NUM_CORES) 而不是 O(1)。但是由于硬件不应该包含在数学中，我们应该假设 NUM_CORES 为 1 或无穷大。无限会导致该算法正常，而假设 1 会导致 GPU 对复杂性没有数学影响。

注意事项：

这不是一个合理的算法，因为内存是 O(n^2)，它更像是一个证明。

值都是不同的，否则会导致两个 rowSum 相等。

虽然有一些方法可以更快地完成这些子步骤，但我还是坚持使用最严格的方法。

【问题讨论】：

标签： algorithm sorting math gpu big-o

【解决方案1】：

答案取决于您是否将处理器的数量视为复杂性分析的相关参数。如果是，那么您必须为处理器的数量引入一个额外的参数，例如 p。

如果您的算法是可扩展的，这意味着时间复杂度与处理器数量成反比线性关系，因此理想情况下您会得到 O(n/p) 而不是 O(n)案子。但这确实是理想的情况，它被称为完美的线性加速。（详情请参阅here。）

但是说 O(n^2) 算法将在 O(n) 中运行在并行机器上肯定是错误的，因为假设处理器的数量会随着输入的大小自动增长是不合理的。

如果您将处理器的数量视为一个常数，则不会发生任何变化。

【讨论】：

【解决方案2】：

这不是渐近运行时复杂性的工作原理。

对于排序，通常的方法是计算比较次数。这是你的方法的一个问题。您似乎计算了所需的一般周期数，并将并行执行的m 比较计数为O(1)。算法还是O(n^2)。它以并行方式运行这一事实并没有与标准方法发生太大变化。

此外，关于渐近运行时复杂性的一点是为lim n->inf 建模您的算法的行为。考虑到这一点，您的 GPU 受到几千个核心（最佳情况）的影响这一事实根本不重要。无论您使用什么底层模型，它只是一个不变的因素。

【讨论】：

【解决方案3】：

您当然可以在计算中包含有限数量的内核，即使您不知道实际数量也是如此。它只是乘以一个常数，这不会影响定义上的 big-O。

很高兴您可以在 O(n) 时间内对 n NUM_CORES 元素进行排序，但 big-O 总是通过取无穷大来计算。这意味着输入大小将始终超过您可用的 GPU 内核数。问题是：那你怎么办？例如，您可以一次对 NUM_CORES 元素的块进行排序，然后对这些排序的块执行重复的合并排序步骤，但这会使您回到（理论上最优的）O(n log n) 的其他排序算法。

因此，虽然您的算法在小输入上可能比非并行算法运行得更快，但仍然不是 O(n)。

【讨论】：