Nano Hash - криптовалюты, майнинг, программирование

Проверка ошибок NPP и CUDA

Я снова унаследовал код, который выглядит подозрительно; это в основном это:

(void) nppiFilter...(...);
cudaError_t err = cudaGetLastError();
if (err != cudaSuccess)
{
    std::cerr << cudaGetErrorString(err);
}

Мы игнорируем ошибку NPP, а вместо этого проверяем наличие ошибки CUDA.

Во-первых, устанавливает ли NPP флаг ошибки CUDA при ошибке? Я почти уверен, что ответ «не явно», поэтому этот код пропустит ошибки только для АЭС, но я хочу проверить.

Во-вторых, нужно ли проверять обе ошибки или этого будет достаточно:

NppStatus nppErr = nppiFilter...(...);
if (nppErr != NPP_NO_ERROR)
{
    std::cerr << "NPP error " << nppErr;
}

Или я должен проверить оба на всякий случай? Есть NPP_CUDA_KERNEL_EXECUTION_ERROR, который подсказывает мне, что, возможно, проверка cudaGetLastError() была бы полезной, но так ли это?

c++ cuda npp
22.05.2018

Ответы:


1

Во-первых, устанавливает ли NPP флаг ошибки CUDA при ошибке?

Нет. Состояние ошибки CUDA может быть установлено чем-то скрытым, что делает NPP, но NPP специально не устанавливает состояние ошибки CUDA.

Или я должен проверить оба на всякий случай?

Должно быть достаточно просто проверить статус АЭС. Однако, если вы хотите выполнить дополнительный анализ отладки, может быть полезно также проверить состояние ошибки CUDA. На самом деле я часто запускаю cuda-memcheck, когда ищу дополнительные подсказки. Единственная нормальная ценность, которую это могло бы иметь, - предоставить «дополнительные подсказки».

Надежным предположением является то, что многие библиотеки CUDA могут иметь функции, которые запускают работу асинхронно. То есть: основная активность графического процессора может продолжаться даже после того, как функция вернула управление потоку ЦП. В таких случаях ожидается, что хорошо спроектированная библиотека будет обнаруживать ошибки из-за асинхронной активности «позже», когда вы выполняете последующий вызов библиотеки или вызов API CUDA (возможно, для извлечения вычисленных данных с устройства на хост).

В таких случаях вы все равно не сможете полагаться на возвращаемое значение функции. Поэтому тщательная проверка ошибок во всей вашей программе — самый безопасный вариант, включая уровень API библиотеки (например, NPP) и уровень API CUDA. Но для производственных целей я бы просто тестировал при каждой возможности, не обязательно предлагая вам вставлять дополнительные проверки, такие как:

error = cudaGetLastError();

(если только он не следует сразу за вызовом API CUDA, и это ваша стратегия**)

и я бы не предложил произвольно вставить:

error = cudaDeviceSynchronize();

Однако, если вы разрабатывали библиотеку, вам может понадобиться некоторая явная проверка ошибок указанного выше типа при входе в ваши функции.

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

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

** Возможно, вы захотите вставить:

error = cudaGetLastError();

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

22.05.2018
  • Спасибо за информацию; в реальном коде я использую эту технику для каждого API и аналогичную сейчас для проверки АЭС с дополнительным #ifdef __cplusplus throw std::runtime_error(cudaGetErrorString(err)); #else exit(-1); #endif. У меня также есть #define за выполнение cudaDeviceSynchronize() перед cudaGetLastError() для лучшей отладки. (Кстати, к счастью, унаследованный код NPP никогда не дает сбоев, в отличие от кода CUDA, который я получил ранее) 22.05.2018
    • Новые материалы
    Кластеризация: более глубокий взгляд
    Кластеризация — это метод обучения без учителя, в котором мы пытаемся найти группы в наборе данных на основе некоторых известных или неизвестных свойств, которые могут существовать. Независимо от..
    Как написать эффективное резюме
    Предложения по дизайну и макету, чтобы представить себя профессионально Вам не позвонили на собеседование после того, как вы несколько раз подали заявку на работу своей мечты? У вас может..
    Частный метод Python: улучшение инкапсуляции и безопасности
    Введение Python — универсальный и мощный язык программирования, известный своей простотой и удобством использования. Одной из ключевых особенностей, отличающих Python от других языков, является..
    Как я автоматизирую тестирование с помощью Jest
    Шутка для победы, когда дело касается автоматизации тестирования Одной очень важной частью разработки программного обеспечения является автоматизация тестирования, поскольку она создает..
    Работа с векторными символическими архитектурами, часть 4 (искусственный интеллект)
    Hyperseed: неконтролируемое обучение с векторными символическими архитектурами (arXiv) Автор: Евгений Осипов , Сачин Кахавала , Диланта Хапутантри , Тимал Кемпития , Дасвин Де Сильва ,..
    Понимание расстояния Вассерштейна: мощная метрика в машинном обучении
    В обширной области машинного обучения часто возникает необходимость сравнивать и измерять различия между распределениями вероятностей. Традиционные метрики расстояния, такие как евклидово..
    Обеспечение масштабируемости LLM: облачный анализ с помощью AWS Fargate и Copilot
    В динамичной области искусственного интеллекта все большее распространение получают модели больших языков (LLM). Они жизненно важны для различных приложений, таких как интеллектуальные..