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( RakingReduction.

sort_by_key最初の内部カーネルを呼び出す前に、内部でメモリ割り当てが行われていると思われます。必要なメモリsort_by_key は (利用可能なメモリがであっても600MB) 利用可能ですsort_by_key。これが発生すると、コンピューターが 1 秒間フリーズすることがわかります。Process Explorerを開いたままにしておくと、CPU物理メモリグラフにも隆起が見られ ます。

sort_by_key使用可能なメモリが少ない場合に、この作業を同じくらい速くするためにできることはありますか? また、メモリ バンプと一時的なフリーズを引き起こしているデバイスとホストの間で何が起こっているのでしょうか?

4

1 に答える 1

1

推力::sort_by_keyは確かにO（N）の一時スペースを割り当てます-基数ソートは、単一のマルチプロセッサで実行できるよりも大きい場合、インプレースソートではありません。したがって、入力データには少なくとも80M * 2 * sizeof（int）= 640MBが必要であり、さらに一時データ用のスペースが必要です。この種類の場合は少なくとも320MBである必要があります。十分なメモリがない場合にソートが失敗しない理由は正確にはわかりません。おそらく600MBは低い見積もりであるか、推力がCPU実行に戻っている可能性があります（そうなるとは思えません）。

パフォーマンスの低下に関する別の考え方は、使用可能なメモリのほとんどすべてが必要な場合、そのような大きなアレイを割り当てるためにドライバ/ランタイムが処理しなければならない使用可能なメモリに少し断片化があり、余分なオーバーヘッドが発生する可能性があるということです。

ところで、利用可能なメモリをどのように測定していますか？

于 2011-07-28T02:28:25.573 に答える