2016-04-08 3 views
1

Я знаю, что это может быть проверено, но меня интересует теория, на бумаге, что должно быть быстрее.Таблица поиска CUDA против алгоритма

Я пытаюсь выяснить, что было бы теоретически быстрее, случайный поиск из таблицы в общей памяти (так возможны банковские конфликты) по сравнению с алгоритмом с произношением «n» fp.

Наилучший сценарий - просмотр общей памяти не имеет банковских конфликтов и поэтому занимает 20-40 тактов, в худшем случае 32 банковских конфликта и 640-1280 тактов. Умножения будут 'n' * циклов на инструкцию. Это правильные рассуждения?

Выполняет ли умножение fp каждый цикл 1? 5 циклов? В какой момент, как число умножений, имеет смысл использовать таблицу просмотра общей памяти?

+1

Рассмотрев эту ситуацию несколько раз в различных контекстах, я бы настоятельно предложил экспериментальный подход. Учитывая сложности выполнения программы на графических процессорах, я не думаю, что компромиссы можно теоретически смоделировать с достаточной точностью на основе общедоступной информации. На графических процессорах вычисление «на лету» часто сравнивает таблицы поиска с точки зрения производительности. – njuffa

+0

Согласование с njuffra на экспериментальном подходе. Это сильно зависит от размера ваших данных. Существует также кеш, который очень эффективен, если ваши данные доступны только для чтения: постоянный кеш. Если ваша таблица поиска подходит вам, вы также захотите попробовать ее, поскольку она не имеет одинаковых правил, таких как разделяемая память (включая выделение). –

ответ

1

Умножения будут «n» x циклов на инструкцию. Это правильные рассуждения? Когда вы выполняете умножения n 'fp, он удерживает ядра в этих операциях. Это, вероятно, не просто «мульти» инструкции, но и другие, такие как «mov». Возможно, это может быть n * 3 инструкций. Когда вы извлекаете кешированное значение из общей памяти (20-40) * 5 (avg max bank conflict..guessing) = ~ 150 часов, ядра могут свободно выполнять другие вещи. Если ядро ​​подсчитывается (ограничено), то использование общей памяти может быть более эффективным. Если ядро ​​имеет ограниченную разделяемую память или использует больше разделяемой памяти, это приведет к меньшему количеству искажений в полете, тогда повторное вычисление будет быстрее.

Выполняет ли умножение fp каждый цикл 1? 5 циклов? Когда я написал this, было 6 циклов, но это было 7 лет назад. Теперь он может (или может и не быть) быстрее. Это только для конкретного ядра, хотя и не для всего SM.

В какой момент, в качестве ряда умножений, имеет смысл использовать таблицу просмотра разделяемой памяти? Это действительно сложно сказать. Здесь много переменных, таких как генератор GPU, что делает остальная часть ядра, время настройки для общей памяти и т. Д.

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

Другим решением (опять же в зависимости от проблемы) будет использование RNG GPU и заполнение массива глобальной памяти случайными числами. Тогда ваше ядро ​​доступа к ним. Это займет 300-500 тактов, но конфликтов банков не будет. Также с Pascal (еще не выпущенный) будет hbm2, и это, скорее всего, еще больше снизит время доступа к глобальной памяти.

Надеюсь, это поможет. Надеюсь, некоторые другие эксперты могут перезвонить и дать вам лучшую информацию.

Смежные вопросы