Как оценить требования к памяти графического процессора для реализации на основе тяги?

У меня есть 3 разных реализации на основе тяги, которые выполняют определенные вычисления: первая — самая медленная и требует наименьшего количества памяти графического процессора, вторая — самая быстрая и требует большей части памяти графического процессора, а третья — промежуточная. Для каждого из них я знаю размер и тип данных для каждого используемого вектора устройства, поэтому я использую vector.size()*sizeof(type) для приблизительной оценки памяти, необходимой для хранения.

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

Я думаю, что для очень длинных векторов, с которыми я имею дело, размер вычисляемой мной функции vector.data() является довольно хорошей оценкой, а остальными накладными расходами (если они есть) можно пренебречь.

Но как мне оценить накладные расходы на использование памяти (если таковые имеются), связанные с реализацией алгоритмов тяги? В частности, я ищу такие оценки для преобразования, копирования, уменьшения, уменьшения_по_ключу и сбора. Меня не особо волнуют накладные расходы, которые являются статическими и не зависят от размеров входных и выходных параметров алгоритма, если только они не очень значительны.

Я понимаю последствия фрагментации памяти графического процессора и т. д., но давайте пока оставим это в стороне.

Большое спасибо, что нашли время, чтобы изучить это.


person Leo    schedule 11.06.2012    source источник
comment
talonmies Спасибо за ответ. Я должен был упомянуть, что я использую тягу 1.5.2, которая поставляется с установкой CUDA 4.2. Насколько я понимаю, для функции «Пользовательское временное размещение» требуется версия 1.6. Это правильно? В какой-то момент я попытался сменить 1.5.2 на 1.6, но после того, как я это сделал, компилятор сообщил мне так много ошибок, что мне пришлось переключиться обратно, потому что в то время я просто не мог позволить себе тратить время на их исправление. . Оказалось, что некоторые векторные конструкторы хоста/устройства больше не доступны или что-то в этом роде.   -  person Leo    schedule 11.06.2012
comment
Лео, Чтобы прокомментировать конкретный ответ, добавьте комментарий к ответу, используя ссылку добавления комментария под ответом.   -  person Heatsink    schedule 11.06.2012
comment
Heatsink, я полностью с вами согласен, но почему-то для меня нет ссылки/кнопки Add Comment под ответом talonmies. Не знаю, почему...   -  person Leo    schedule 12.06.2012
comment
talonmies, я принял твой ответ. Спасибо за помощь.   -  person Leo    schedule 13.06.2012


Ответы (1)


Thrust предназначен для использования в качестве черного ящика, и нет никакой документации о накладных расходах памяти различных алгоритмов, о которых я знаю. Но это не кажется очень сложной проблемой, чтобы вывести это эмпирически, проведя несколько численных экспериментов. Вы можете ожидать, что потребление памяти конкретным алгоритмом будет примерно таким:

total number of words of memory consumed = a + (1 + b)*N

для проблемы с N входными словами. Здесь a будут фиксированными накладными расходами алгоритма, а 1+b наклоном наилучшего соответствия памяти по сравнению с N строкой. b - это количество накладных расходов алгоритма на входное слово.

Таким образом, возникает вопрос, как контролировать использование памяти данным алгоритмом. Thrust использует внутреннюю вспомогательную функцию get_temporary_buffer для выделения внутренней памяти. Лучшей идеей было бы написать собственную реализацию get_temporary_buffer, которая выдает размер, с которым она была вызвана, и (возможно) использует вызов cudaGetMemInfo для получения статистики контекстной памяти во время вызова функции. Вы можете увидеть несколько конкретных примеров того, как перехватывать get_temporary_buffer вызовов здесь.

Имея соответствующий инструментарий распределителя и несколько прогонов с ним при нескольких разных размерах задач, вы должны быть в состоянии подогнать приведенную выше модель и оценить значение b для заданного алгоритма. Затем модель можно использовать в вашем коде для определения безопасных максимальных размеров задач для заданного объема памяти.

Надеюсь, это то, о чем вы спрашивали...

person talonmies    schedule 11.06.2012