Оптимизация GPGPU


Графический процессор — самый мощный из доступных процессоров. Сейчас есть попытки упростить использование для неграфических вычислений — введите GPGPU.

GPU — графический процессор — внутри большинства современных машин представляет собой параллельный суперкомпьютер, предназначенный для рендеринга сложной графики. Программистам не потребовалось много времени, чтобы заметить, что именно эта часть оборудования способна выполнять более общие задачи — отсюда GPGPU, General Purpose GPU.

Первоначально проблема с использованием графического процессора для приложений обработки чисел заключалась просто в отсутствии инструментов. Было сложно даже попытаться использовать графический процессор по назначению. Добавьте к этому различия в аппаратном обеспечении графических процессоров и тот факт, что ранние графические процессоры были примитивными в предоставляемых ими возможностях, и вы сможете начать понимать трудности. Приложения создавались с использованием графических инструментов, таких как OpenGL или DirectX, и должны были быть реализованы в графических терминах.

Однако по мере того, как ситуация улучшалась — мы продвигались к модели шейдеров 3.0 и таким инструментам, как CUDA, SDK, который позволяет программировать GPU на языке C, поэтому его использование для вычислений общего назначения росло. У Microsoft также есть DirectCompute, расширение для DirectX, которое позволяет писать приложения GPGPU на HLSL.

Ключевая идея — это ядро. Большинство программ на GPU работают с 2D-массивом пиксельных данных и имеют встроенный неявный цикл double for, который эффективно сканирует весь массив. При программировании графического процессора вам нужно указать только ядро цикла, потому что указанный вами код автоматически применяется к каждому пикселю. Причина, по которой графический процессор реализует это быстрее, чем говорит ЦП, заключается просто в том, что у него много процессоров, которые обрабатывают данные пикселей параллельно. Таким образом, графический процессор является примером подхода SPMD с одной программой и несколькими данными к параллельной архитектуре.

В случае современного графического процессора статистика впечатляет — обычно 16 потоковых мультипроцессоров, каждый с 8 потоковыми процессорами. Каждый из этих процессоров занят большим количеством потоков. Вы можете подвести итог, сославшись на обычную статистику: 10 гигафлоп для процессора и 1 терафлоп для графического процессора. Это немного вводит в заблуждение, поскольку графический процессор может работать с такой скоростью только с данными, имеющими правильную структуру, но он хорош для общих задач, связанных с матрицами.

В настоящее время одна из проблем заключается в том, что природа оборудования затрудняет написание функций ядра, которые работают как можно быстрее. Небольшие изменения в коде могут существенно повлиять на эффективность, и эти изменения не очевидны или интуитивно понятны, и они зависят от оборудования. Теперь группа исследователей сделала первые несколько шагов в создании оптимизирующего компилятора, который обеспечивает увеличение скорости в 128 раз по сравнению с неоптимизированной функцией ядра и опережает оптимизированный вручную код примерно на 30%. Компилятор имеет открытый исходный код и может быть модифицирован для работы с другим оборудованием: компилятор GPGPU для оптимизации памяти и управления параллелизмом.

Альтернативный подход — ручная оптимизация, и это также дает преимущество нового инструмента. Только что был выпущен ATI Stream Profiler v1.3. Это интегрируется с Visual Studio и собирает данные графического процессора при запуске приложения OpenCL.


Добавить комментарий