Что на самом деле делает pycuda.debug?

#python #debugging #cuda #gpgpu #pycuda

#python #отладка #cuda #gpgpu #pycuda

Вопрос:

В рамках более крупного проекта я столкнулся со странно последовательной ошибкой, которая не укладывается у меня в голове, но является архетипичной ошибкой «черного ящика»; при запуске с cuda-gdb python -m pycuda.debug prog.py -args она работает нормально, но медленно. Если я удаляю pycuda.debug, он ломается. Последовательно, в точно такой же момент при выполнении на нескольких ядрах.

Чтобы объяснить; У меня есть (в настоящее время три) ядра, используемые в разных схемах сетки и блоков для решения «фрагментов» более крупной задачи оптимизации. Строго говоря, они должны либо работать, либо нет, поскольку самим функциям ничего не сообщается, кроме «вот еще некоторые данные», и, кроме содержимого данных, ничего не известно, например, номер итерации, разделены ли их входные данные или нет, и вплоть до этого момента они работают идеально.

В принципе, я не вижу, что происходит, если pycuda.debug не предоставляет отладочные символы в GDB, но я также не вижу проблемы С pycuda.debug.

Что на самом деле делает pycuda, чтобы я знал, что искать в моем коде ядра?

Ответ №1:

Почти ничего. В основном он устанавливает флаги компилятора в модуле pycuda.driver, так что код CUDA компилируется с необходимыми символами отладки и собирается так, как того требует CUDA-gdb. Остальное — это крошечная оболочка, которая красиво инкапсулирует библиотеки pycuda, чтобы все работало. Все это примерно в 20 строках python, вы можете посмотреть код в исходном дистрибутиве, если хотите.

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

Комментарии:

1. Как ни странно, в данный момент я не использую никакой общей памяти! (Раньше я обжигался на преждевременной оптимизации) но что странно, так это то, что в этой конкретной итерации данных нет ничего особенного по сравнению с другими тысячами или около того почти идентичных исполнений ядра. В любом случае требуется дополнительное расследование, спасибо.

2. @Andrew Bolster: Если вы готовы сделать код доступным где-нибудь, я мог бы попробовать его протестировать. В настоящее время в моем распоряжении имеется ряд видеокарт на базе GT200 и Fermi.

3. Решил это; Проблема, над которой я работаю, иногда может быть численно нестабильной, и одна из ограничивающих переменных была установлена неправильно. Спасибо за предложение!