Объектно-ориентированное программирование на C++-AMP

Мне нужно обновить некоторый код, который я использовал для алгоритма Ахо-Корасика, чтобы реализовать алгоритм с использованием графического процессора. Однако код сильно зависит от модели объектно-ориентированного программирования. Мой вопрос: можно ли передавать объекты parallel for each? Если не; есть ли какой-нибудь обходной путь, который может быть работоспособным и освободить меня от повторного написания всего кода. Мои извинения, если это кажется наивным вопросом. C++-AMP — это первый язык, который я использую в программировании GPU. Следовательно, мой опыт в этой области довольно ограничен.


person Hawk    schedule 04.11.2013    source источник


Ответы (1)


Ответ на ваш вопрос - да, поскольку вы можете передавать классы или структуры лямбде, отмеченной restrict(amp). Обратите внимание, что parallel_foreach` не ограничен AMP, его лямбда ограничена.

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

C++ AMP-совместимая функция или лямбда-выражение могут использовать только C++ AMP-совместимые типы, в том числе следующие:

  • инт
  • беззнаковое целое
  • плавать
  • двойной
  • Массивы в стиле C из int, unsigned int, float или double
  • concurrency::array_view или ссылки на concurrency::array
  • структуры, содержащие только типы, совместимые с C++ AMP

Это означает, что некоторые типы данных запрещены:

  • bool (может использоваться для локальных переменных в лямбда-выражении)
  • уголь
  • короткая
  • долго долго
  • неподписанные версии вышеуказанного

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

... Из книги C++ AMP, глава 3.

Поэтому, хотя вы можете это сделать, это может быть не лучшим решением по соображениям производительности. Кэши CPU и GPU несколько отличаются. Это делает массивы структур лучшим выбором для реализации ЦП, тогда как графические процессоры часто работают лучше, если используются структуры массивов.

Аппаратное обеспечение графического процессора предназначено для обеспечения наилучшей производительности, когда все потоки в варпе последовательно обращаются к памяти и выполняют одни и те же операции с этими данными. Следовательно, неудивительно, что память графического процессора спроектирована так, чтобы быть наиболее эффективной при таком доступе. На самом деле, операции загрузки и сохранения в одну и ту же линию передачи разными потоками в варпе объединяются всего в одну транзакцию. Размер линии передачи зависит от аппаратного обеспечения, но, как правило, ваш код не должен это учитывать, если вы сосредоточитесь на том, чтобы доступ к памяти был как можно более непрерывным.

... Ch. 7.

Если вы посмотрите на реализации ЦП и ГП в моем примере с n-телом, вы увидите реализации обоих подходы для CPU и GPU.

Сказанное выше не означает, что ваш алгоритм не будет работать быстрее, если вы перенесете реализацию на C++ AMP. Это просто означает, что вы можете оставить некоторую дополнительную производительность на столе. Я бы рекомендовал сделать самый простой перенос, а затем подумать, хотите ли вы потратить больше времени на оптимизацию кода, возможно, переписав его, чтобы лучше использовать преимущества архитектуры графического процессора.

person Ade Miller    schedule 05.11.2013