Тяга: sort_by_key медленный из-за выделения памяти - PullRequest
Новая
       20

Тяга: sort_by_key медленный из-за выделения памяти

0 голосов
/ 07 июля 2011

Я делаю sort_by_key с массивами ключ-значение размером 80 миллионов. Устройство представляет собой GTX 560 Ti с 2 ГБ VRAM. Когда доступно (бесплатно) память до sort_by_key равна 1200MB, сортировка заканчивается в 200ms. Но когда доступная память падает до 600MB, sort_by_key для тот же массив значений ключа занимает 1.5-3s!

Я запустил программу под Compute Visual Profiler . Я обнаружил, что ГПУ отметка времени скачет на 1,5-3 с между последним ядром до sort_by_key и первый вызов ядра внутри sort_by_key (который является RakingReduction).

Я подозреваю, что внутри sort_by_key происходит выделение памяти, прежде чем он вызовет свое первое внутреннее ядро. Память, которая sort_by_key потребности доступны (даже если доступная память 600MB), так как sort_by_key работает, хотя и медленнее. Я вижу, что компьютер зависает на 1с, когда это происходит. Я также вижу удар в процессоре Физическая память график, если я держу Process Explorer открытым.

Могу ли я что-нибудь сделать, чтобы это sort_by_key работало так же быстро? когда доступная память меньше? Кроме того, что происходит между устройство и хост, который вызывает скачок памяти и временный замораживания

1 Ответ

1 голос
/ 28 июля 2011

thrust :: sort_by_key действительно выделяет временное пространство O (N) - радикальная сортировка не является сортировкой на месте, когда она больше, чем это может сделать один мультипроцессор. Поэтому вам нужно по крайней мере 80M * 2 * sizeof (int) = 640MB для входных данных плюс пространство для временных файлов, которое должно быть не менее 320MB для этого вида. Я не совсем уверен, почему сортировка не происходит просто так, когда у вас недостаточно памяти - возможно, 600 МБ - это заниженная оценка, или, возможно, откат к выполнению ЦП (я сомневаюсь, что это так).

Еще одна идея о снижении производительности заключается в том, что когда вам нужно почти всей доступной памяти, в доступной памяти может возникнуть некоторая фрагментация, с которой драйвер / среда выполнения должны иметь дело, чтобы выделить такие большие массивы, вызывая дополнительные издержки.

Кстати, как вы измеряете доступную память?

...