В статье рассматривается использование платформы Java для разработки совместно с OpenCL, преимущества и недостатки этого подхода. Сочетание этих технологий в разработке ПО в перспективе позволит использовать всю мощь облачных вычислений и OpenCL

В последнее время набирает популярность разработка программного обеспечения для серийно выпускаемых вычислительных устройст с высокой степенью параллелизма. Это современные многоядерные процессоры с SIMD коммандами и видеоускорители с поддержкой GPGPU (General-purpose computations on GPU), устройства сочитающие центральный и графический сопроцессор на одном кристале AMD Fusion, а так же специализированные сопроцессоры. Почти у каждого типа устройств своя система комманд, архитектурные особенности и разработка приложений ранее требовала от разработчика знаний нескольких языков программирования и API (интерфейсов программирования приложений). Все это сильно усложняло программирование, а также делало невозможным или экономически нецелесообразным смену платформы (vendor lock-in). Альянсом производителей аппаратного и программного обеспечения был разработан и стандартизован язык OpenCL, который решает эти проблемы. Это открытый стандарт и существует несколько реализаций от разных производителей аппаратного обеспечения AMD, Intel, Nvidia, IBM и др. под операционные системы Windows, Linux и MacOS.

Под ОС Windows для VisualStudio есть плагины от NVIDIA — Parallel Nsight и gDEBugger от AMD. И если с OpenCL компилятором и runtime средой выполнения для перечисленных ранее операционных систем нет проблем, то со средой разработки под Linux у AMD/Nvidia все гораздо сложнее.

Когда host код — часть кода OpenCL, которая подготавливает данные и координирует работу OpenCL ядер, написана на Java, в ОС Linux/Windows возникают проблемы с отладкой. Если вспомнить успех Java платформы на рынке разработки кросплатформенного серверного ПО, непонятно почему вендоры аппаратного обеспечения до сих пор не разрабатывают средства разработки OpenCL — отладки и профилирования, встроенных в Eclipse IDE, Netbeans IDE, IntelliJ Idea. А пока эти среды разработки не включают готовый инструментарий, упрощающий работу с рассматриваемой технологией, попробуем решить задачи разработки средствами доступными сегодня. Это позволит получить нам конкурентоспособное промышленное решение, оптимизированное для работы на современных вычислительных устройствах.

Преимущества и недостатки при совместном использовании Java и OpenCL

Итак почему стоит использовать платформу Java для разработки host кода для OpenCL? Приведу несколько доводов в пользу такого выбора:

• Кросплатформенность — виртуальная машина Java (JVM) существует для множества платформ — Windows, Linux, MacOS, Unix. «Write once, run anywhere.» Также есть реализации от различных производителей JVM, open source реализации;
• Огромное количество разработчиков/архитекторов знающих эту платформу. Простота и удобство коллективной разработки, тестирования, удобство отладки и профилирования, выпуска ПО и доставки модулей системы в production;
• Большое число open source библиотек доступных для использования в разработке. Неисчеслимое количество источников и потребителей данных, доступных в java приложениях (http, soap,rest, smtp, scp, jms, CORBA, базы данных — реляционные/NoSQL и т.д.), например из компонентов Apache Camel;
• Платформа для облачных приложений: наличие фреймворков для разработки распределенных и эластичных приложений, обработки огромных объемов данных, например с помощью Apache Hadoop;
• Признанный корпоративный(enterprise) стандарт в банках, финансовых учреждениях, телекомуникационной сфере: большой штат системных администраторов, способных поддерживать работу JVM;
• Множество языков программирования, способных выполняться в JVM: jruby, PHP(Caucho quercus), jython, javascript (Mozilla Rhino), Scala и т.д. Существование большого числа языков позволяет как оптимизировать существующие приложения, так и более продуктивно разрабатывать новые. Как следствие in-process вызовы из этих языков java классов использующих OpenCL. Иногда бывает лучше использовать OpenCL API binding именно для используемого языка. Иногда фреймворки используемые в DSL пишутся на java одними разработчиками и используются другими разработчиками в языках программирования внутри JVM для быстрой разработки приложений;
• JavaCL — компактный и объектно-ориентированный API для OpenCL host кода.

Когда не стоит использовать Java для написания OpenCL host кода:

• Недетерменированность работы сборщика мусора. Вашему приложению могут требоваться низкие задержки при обработке данных и выдаче ответа (например трейдинговая система или управляющая программа для медицинского оборудования);
• Наличие больших накладных расходов на копирование данных между JVM и native кодом, в т.ч. реализации OpenCL. Сюда же можно отнести отсутствие для jvm кода, который может считывать и записывать необходимые вам данные;
• Алгоритм невозможно эффективно реализовать в рамках архитектуры OpenCL. Не все алгоритмы хорошо распараллеливаются(закон Амдаля-Уэра), время передачи данных по шине может быть во много раз больше время вычислений на устройстве и т.п. Эта проблема имеет отношение к алгоритму и подходу вобщем, а не к java в частности. Никакой host код для вызовов OpenCL API не сможет быть полезен в этом случае.

Итак, решили что наша задача подходит для OpenCL и ее невозможно так же эффективно реализовать используя только язык Java. В то же время хотим использовать преимущества JVM. Перейдем от идеи к реализации.

Технологии

Рекомендую для разработки OpenCL в реализации от AMD, если в перспективе планируется перейти к использованию серверного процессора APU Opteron вместо desktop решения на базе CPU AMD + Radeon HD 5000/6000 или AMD Fusion. JavaCL в качестве API для работы с OpenCL. Используя bridJ для вызова native кода динамической библиотеки OpenCL API, получаем прирост производительности по сравнению с JNA.

Инструментарий отладки: gdb с text user interface или ddd как фронтэнд gdb

Для профилирования кода рекомендую использовать AMD APP Profiler из AMD Accelerated Parallel Processing (APP) SDK, ОС Ubuntu 11.04 с установленным AMD proprietary FGLRX graphics driver для разработки. Разработка может вестись в любой Java IDE, поддерживающей maven проекты. Но поддержку подсветки синтаксиса и компиляции OpenCL функций во время написания кода на данный момент поддерживает только плагин для netbeans. Работа этого плагина оказалась крайне не стабильна.

Создание инфраструктуры для разработки и процесс разработки не отличается от работы с другими java технологиями.

С инструментарием отладки все сложнее, но есть решение и этой проблемы. Среда выполнения OpenCL от AMD позволяет отлаживать ядра при запуске на CPU: ставить точки останова (breakpoint) и отображать значения переменных, в том числе векторных типов float4, int4 и т.п. При этом на центральном процессоре эмулируются функции GPU, например для работы с текстурами. Для интересующихся деталями отладки есть статья об отладке JavaCL и OpenCL под linux. Также автором проекта создана wiki страница про отладку кода ядер из Java. Подробная информация о поддерживаемых расширениях gdb для OpenCL

Для профилирования приложения можно использовать AMD APP Profiler. При запуске в Linux он позволяет собрать статистику о работе OpenCL функций в приложении и сохранить ее в CSV файл для последующего анализа данных в табличном процессоре LibreOffice Calc. Чтобы понять насколько оптимально работает ваш код, нужно интерпретировать значения параметров измеряемых профайлером.

Заключение

В статье рассмотрели преимущества и недостатки разработки программного обеспечения с использованием платформы Java и технологии OpenCL. Благодаря перспективам развития вычислительных устройств в по пути увеличения параллелизма, данный подход в разработке ПО претендует на то чтобы стать одним из основных в разработке высокопроизводительных enterprise и cloud преложений на JVM.