我正在使用大小为8000万的键值int数组进行sort_by_key。
该设备是 GTX 560 Ti ，具有 2GB VRAM。什么时候可用（免费）
sort_by_key为1200MB之前的内存，它完成了200ms中的排序。
但是，当可用内存降至600MB时，sort_by_key为。{
相同的键值数组需要1.5-3s！
我在 Compute Visual Profiler 下运行该程序。我发现了GPU
sort_by_key之前的最后一个内核之间的时间戳跳跃1.5-3s
和sort_by_key内的第一个内核调用（这是一个
RakingReduction）。
我怀疑在sort_by_key内部正在进行内存分配，
在它调用它的第一个内部内核之前。 sort_by_key的记忆
需求是可用的（即使可用内存为600MB），因为
sort_by_key有效，即使速度较慢。我看到了电脑
发生这种情况时冻结1秒。我也看到CPU出现问题
物理内存图表，如果我保持 Process Explorer 打开。
我能做些什么来使sort_by_key同样快速地工作
什么时候可用内存较小？此外，之间发生了什么
导致内存崩溃和临时的设备和主机
冷冻？
答案 0 :(得分：1)
thrust :: sort_by_key确实分配了O（N）的临时空间 - 当基数大于单个多处理器时，基数排序不是就地排序。因此，输入数据需要至少80M * 2 * sizeof（int）= 640MB，临时空间必须至少为320MB。我不确定为什么当你没有足够的内存时，排序不会失败 - 或许600 MB是一个低估计，或者可能推回到CPU执行（我怀疑它是这样）。
关于性能下降的另一个想法是，当你需要几乎所有可用内存时，可用内存中可能会有一些碎片，驱动程序/运行时必须按顺序处理分配这样大的数组，造成额外的开销。
顺便说一下，你如何衡量可用内存？