0

我正在做一个sort_by_key大小为 8000 万的键值 int 数组。该设备是具有2GB VRAM的GTX 560 Ti 。当 sort_by_key 之前的可用（空闲）内存为时，它将完成排序。但是，当可用内存下降到 时，相同键值数组的 sort_by_key 需要!1200MB200ms600MB1.5-3s

我在Compute Visual Profiler下运行该程序。我发现 GPU 时间戳在之前的最后一个内核sort_by_key 和内部的第一个内核调用sort_by_key（即 a RakingReduction）之间跳跃了 1.5-3 秒。

sort_by_key我怀疑在调用它的第一个内部内核之前，内部已经完成了内存分配。需要的内存sort_by_key 是可用的（即使可用内存是600MB），因为 sort_by_key工作正常，即使速度较慢。我看到发生这种情况时计算机会冻结 1 秒。如果我保持进程资源管理器打开，我还会在 CPU物理内存图中看到一个凸起 。

当可用内存较少时，我能做些什么来使这项sort_by_key工作同样快吗？此外，导致内存碰撞和暂时冻结的设备和主机之间发生了什么？

4

1 回答 1

1

推力::sort_by_key 确实分配了 O(N) 的临时空间——当基数排序大于单个多处理器可以完成时，它不是就地排序。因此，输入数据至少需要 80M * 2 * sizeof(int) = 640MB，加上临时空间，这种排序至少需要 320MB。我不确定为什么当你没有足够的内存时排序不会失败——也许 600 MB 是一个较低的估计值，或者推力正在回落到 CPU 执行（我怀疑它会这样做）。

关于性能下降的另一个想法是，当您需要几乎所有可用内存时，驱动程序/运行时必须处理可用内存中的一些碎片以分配如此大的数组，从而导致额外的开销。

顺便说一句，您如何测量可用内存？

于 2011-07-28T02:28:25.573 回答