7994420702;horizontal

Pentium4 производства AMD, часть 5

Использование OpenCL  

Производители GPU договорились унифицировать язык программирования, чтобы обеспечить совместимость программ с GPU различных вендоров. Это совсем не сложно, как уже было отмечено выше, микроархитектуры всех графических процессоров достаточно схожи. Но все-таки интересен вопрос, на сколько быстро будет выполняться OpenCL-программа, разработанная на одном GPU, на системе с карточкой другого производителя?

В первую очередь, это должно быть интересно AMD, так как NVIDIA предоставляет более отлаженную платформу и разрабатывать будут в первую очередь на ней. Надо сказать, если программа не очень глубоко оптимизирована под конкретный GPU, просто параллельная OpenCL-программа, то её архитектурные предпочтения равновероятны независимо от того, на какой архитектуре она разрабатывалась. Но если программа жёстко ориентируется на специфику GPU NVIDIA, в первую очередь на размер варпа, она сама разбивает нити на пучки по 32 и внутри варпа не предполагается дивергентных ветвлений, только различные варпы могут разбегаться по программе, то на AMD, с её вдвое большим размером warp, такая программа легко может работать в два раза медленней.

Также, GPU могут отличаться в оптимальной организации доступа к памяти. Если программа очень жёстко настроена на специфику банков памяти NVIDIA, то она не получит такого же прироста от этой оптимизации на Radeon. Надо сказать, что на данный момент тонкие вопросы оптимизации доступа к памяти очень слабо документированы для Radeon, и в целом документация не совсем полна и непонятно организована. Документация на CUDA выглядела несколько смутной, по сравнению с руководствами по программированию и оптимизации для CPU, а документация AMD выглядит смутной по сравнению с описаниями CUDA.

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

Например, у Fermi, GT200 и Radeon различный размер локальной памяти. 48 Кб (без учета 16 Кб L1), 16 Кб и 32 Кб соответственно. Для NVIDIA часто лучше ориентироваться на размер памяти 16 Кб, в этом случае программа пойдет на всех GPU — и старых, и новых. А Fermi сможет просто 3 блока нитей исполнять вместо одного на GT200, так как он, со своими 48 Кб памяти, будет выглядеть как три минипроцессора старого образца. А для AMD лучше сделать вариант с использованием 32 Кб локальной памяти, он будет быстрее работать, вероятно. Если бы Evergreen был неким стандартом, самым массовым продуктом, на который в первую очередь ориентируются разработчики, то могли бы пострадать уже изделия NVIDIA. Следующим образом, программа ориентируется на размер локальной памяти 32 Кб, для 16 Кб GT200 запускается какой-то совместимый вариант, который работает не очень оптимально, а на Fermi не используется дополнительный размер кэша, а только 32 Кб, хотя он на самом деле больше.

Также, для Radeon желательна векторизация и использование векторных типов данных, в том числе чтобы загрузить векторные регистры. И более агрессивное избавление от ветвлений. Некоторые фирмы смогут выделить ресурсы для эквивалентной оптимизации, некоторые вообще не озаботятся низкоуровневой оптимизацией. Можно сказать, что ситуация, отчасти, напоминает ситуацию с десктопными процессорами, где Intel гораздо лучше поддерживает разработчиков, только тут в роли Intel выступает NVIDIA.

Вот если бы поменять местами программную поддержку NVIDIA и AMD, то есть: AMD работала бы над продвижением GPU, как NVIDIA сейчас, CUDA бы работала уже давно на Radeon, а на GeForce был бы Brook+ и недоделанный компилятор OpenCL, то с учётом доступности в настоящее время, относительной дешевизны и высокой пиковой производительности Evergreen, он бы стал фактическим стандартом, как Pentium 4 в своё время. Однако можно снова сказать, что у AMD несколько другие планы, и универсальные вычисления на GPU для неё вторичны.

Но с точки зрения прироста относительно тех же процессоров, который в удобных для GPU случаях составляет разы и порядки, отличия в скорости между NVIDIA и AMD в десятки процентов из-за различного уровня оптимизации, смотрятся не так значительно и принципиально.

НазваниеКоличество чиповЧастотаКоличество SIMD EngineКоличество VLIW модулейПроизводительность в floatПроизводительность в double
Radeon HD5970 2 725 MHz 40 640 4,64 TFLOPS 928 GFLOPS
Radeon HD5870 1 850 MHz 20 320 2,72 TFLOPS 544 GFLOPS
Radeon HD5850 1 725 MHz 18 288 2,09 TFLOPS 418 GFLOPS
Radeon HD5770 1 850 MHz 10 160 1,36 TFLOPS
Radeon HD5750 1 700 MHz 9 144 1,008 TFLOPS
Radeon HD5670 1 775 MHz 5 80 0,620 TFLOPS

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

Ссылки  

9 февраля 2010 года
20 сентября 2010 года






Похожие статьи

  • Проблемы и преимущества Fermi

    Выход представителей нового поколения графических процессоров NVIDIA несколько раз откладывался, в итоге первые GeForce и Tesla на новой архитектуре вышли урезанными, относительно первоначально заявленных спецификаций. Они так же неприятно удивили довольно высоким уровнем энергопотребления. Что послужило причиной задержек? И стоило ли ждать? Какие особенные архитектурные инновации выделяют Fermi и делают его уникальным?

  • Развитие вычислений на GPU: преимущества архитектуры Fermi

    Прошло всего три года со дня выхода в свет GPU c поддержкой CUDA, но за это время не только производительность видеокарт NVIDIA выросла на порядок, но и программная архитектура приобрела практически завершенный вид.

  • Параллельные вычислительные процессоры NVIDIA: настоящее и будущее

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

  • Параллельные вычисления на GPU NVIDIA или суперкомпьютер в каждом доме

    До недавнего времени забытый пароль архивов RAR означал потерю заархивированных данных практически навсегда. Мощностей отдельно взятого компьютера было в принципе недостаточно для атаки методом перебора «в лоб», а распределённые вычисления и более сложные способы подбора были доступны лишь немногим. Но мощные графические процессоры и технология NVIDIA CUDA внесли коррективы (конкурсная работа).

  • Проблемы трассировки лучей — из будущего в реальное время

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