Я немного искал, и я думаю, что следующий вариант ответа на ваш вопрос.
Цитата Н. Белла и Дж. Хоберока, «Thrust: ориентированная на производительность библиотека для CUDA», в GPU Computing Gems Jade Edition:
Thrust статически выбирает оптимизированный алгоритм Radix Sort для сортировки примитивных типов (char
, int
, float
и double
) с помощью стандартных операторов сравнения less
и greater
. Для всех других типов (например, определяемых пользователем типов данных) и операторов сравнения Thrust использует общий алгоритм сортировки слиянием. Поскольку сортировка примитивов с помощью Radix Sort значительно быстрее, чем сортировка слиянием, эта статическая оптимизация имеет большое значение.
Теперь для сортировки слиянием требуется O(N)
памяти, см. Требования к пространству для сортировка слиянием.
Кроме того, Radix Sort по-прежнему требует O(N)
памяти, см. Сравнение Bucket Sort и RADIX Сортировать.
Какой из двух потребляет больше памяти, не определено и зависит от входной последовательности, которую нужно отсортировать, а также от параметров настройки алгоритма, см. Комментарии к одному из ответов на Почему быстрая сортировка более популярна, чем Radix-сортировка?.
Напротив, Быстрая сортировка требует O(logN)
памяти, если выполняется на месте, в противном случае требуется O(N)
. Для реализации CUDA алгоритма быстрой сортировки вы можете посмотреть Как Tesla K20 ускоряет быструю сортировку.
Для других алгоритмов сортировки на месте (стратегию на месте стоит изучить, поскольку она экономит память по сравнению с не на месте em> аналог), посмотрите Bitonic Sort, см. Быстрая сортировка на месте с помощью CUDA на основе битонной сортировки.
person
Vitality
schedule
01.07.2014
thrust::merge_by_key
там, что может быть менее затратно, чем выполнение полной сортировки на хосте, но время передачи устройства хоста ‹-›, вероятно, сделало бы такой подход тоже неинтересно. - person Robert Crovella   schedule 01.07.2014