Разработка на Java и OpenCL: Дорога в облака



    В статье рассматривается использование платформы 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.
    Ads
    AdBlock has stolen the banner, but banners are not teeth — they will be back

    More

    Comments 13

      –4
      Я думаю что в ближайшем будущем (лет через 5 скорее всего) появится имплементация виртуальной машины Java которая будет использовать OpenCL для ускорения исполнения виртуального кода что вполне теоритически возможно
        +2
        Меня всегда улыбает фраза "… появится имплементация виртуальной машины Java которая ...".
        В HotSpot влиты просто огромные количества человеко-лет. Java является самой распространенной промышленной платформой отчасти благодаря своей предсказуемости. Даже версия от IBM, не смотря на свои возраст, стабильность и всякие RT ништяки занимает небольшой сегмент рынка.
          0
          в Android-е появился Renderscript
          конечно это что-то вроде связки Java+JavaCL (это не JVM-CL), но желание опробовать (и вложиться во что-то) новое от Google похвально
            0
            Вряд ли это возможно в текущем виде реализации технологии OpenCL. Она приминима лишь к определенному кругу задач, есть границы применимости связанные с особенностью аппаратного обеспечения. Мне кажется перспективным в ближайшие годы — реализация части алгоритмов с java коллекциями на OpenCL по аналогии со ScalaCL и реализация fork-join фреймворка с использованием java closure которые транслируются в OpenCL функции по аналогии с проектом Aparapi. Также отлично вписываются в технологию задачи обработки/фильтрации изображений java2D/JAI. Но JAI похоже умер так и не родившись, по крайней мере опыт работы с ним оставил неприятные воспоминания(
              0
              Не думаю, что «появится имплементация виртуальной машины Java которая будет использовать OpenCL» в ближайшие 5 лет. Это только на словах OpenCL универсальный стандарт, на деле — он сильно зависит от аппаратной архитектуры со всеми вытекающими отсюда приветами. Даже если посмотреть со стороны аппаратной части, то OpenCL поддерживают AMD, NVIDIA, Intel (только в процессорных версиях), остальных я брать не буду ибо распространённость маленькая.
              AMD — активно продвигает OpenCL
              NVIDIA — продвигает OpenCL, но так же продвигает и CUDA. Основная ставка на CUDA
              Intel CPU — поддерживает OpenCL, но смысла в этом нет, т.к. люди привыкли программировать по другому да и архитектурно оно сильно отличается от GPU
              Intel MIC — неясно что с поддержкой OpenCL, основной позыв на директивы

              Таким образом, появление данной виртуальной машины будет работать только на AMD, либо их будет несколько для AMD, NVIDIA, Intel.
                0
                Вы правы Насчет аппаратных особенностей и оптимизации алгоритма под конкренные платформы.

                Разработка оптимальных с точки зрения производительности OpenCL функций для GPU и CPU требует знания аппаратных особенностей платформы исполнения. Но, синтаксис и набор функций един в стандарте и host API один и тот же для разных реализаций. Т.е. с точки зрения разработчика достаточно выучить один язык (вместо Brook+, CUDA и т.п. для каждой платформы) и один переносимый host API. Это позволяет разработчику углубиться на оптимизации ядер на одном языке под каждую платформу. С помощью API можно узнать тип устройства и производителя и вызвать функцию оптимизированную под данную платформу.

                Ситуация со стандартом OpenCL такая же как и с OpenGL в свое время. До появления аппаратуры от Nvidia и их драйверов, на массовом рынке для Windows не было производительных реализаций драйверов OpenGL. Был зоопарк проприетарных API: Glide/DirectX привязанных к конкретным вендорам. С появлением нового производителя аппаратных 3D карт на рынке и большого колличества программ использующих OpenGL, качество драйверов от различных производителей улучшилось!

                OpenCL от Nvidia реализован над CUDA и по данным с разных статей производительность на 10% хуже.
                Ждем появления большого колличества ПО использующих OpenCL и тогда вендоры будут оптимизировать драйвера/компиляторы, чтобы их платформа была лучше чем конкурентов по производительности.

                Наличие универсального языка позволяет упростить разработку и чем больше разработчиков будут знать OpenCL тем проще будет найти разработчика для реализации проекта. Главное чтобы разработчик имел достаточно знаний по каждой поддерживаемой программой аппаратной платформе.

                Общие тенденции развития hardware: AMD Fusion, IntelMIC, IBM Cell, Nvidia ARM, свидетельствуют что для разработки ПО для новых платформ нужен язык, поддерживающий многопоточность, встроенные в язык векторные типы и обширную библиотеку алгоритмов обработки данных, а также большое колличество специалистов владеющих языком программирования и инструментарием разработки.

                По поводу JIT в OpenCL я описал свое мнение в комментарии выше)
                0
                Проект Sumatra

                This primary goal of this project is to enable Java applications to take advantage of graphics processing units (GPUs) and accelerated processing units (APUs)--whether they are discrete devices or integrated with a CPU--to improve performance.


                А человеку минусов наставили.
                  0
                  Как-то затих этот проект. По крайней мере идея в основе sumatra отличная. Сложность реализации этого проекта достаточно высокая.
                  Под капотом там не OpenCL, некий промежуточный код HSA, в который скоро будет транслироваться и OpenCL. И такой технологии в jvm есть на платформах с поддержкой Shared Virtual Memory
                –3
                кстати,
                если в статье заменить Java на .NET/Mono, а JavaCL на Cloo(есть в OpenTK)/OpenCL.NET,
                то статью с тем же успехом и выводами можно читать и приверженцам .NET :)
                  0
                  Да такой подход применим и для .NET/Mono и Cloo. Мой опыт разработки связан с jvm. Каждый кулик хвалит свое болото ;) Если напишите пост про опыт разработки Mono/Cloo + OpenCL под linux, с удовольствием почитаю.
                  0
                  Может кто знает как называется чип от Nvidia на платформе ARM?
                    0
                    возможно, Tegra?
                    0
                    Спасибо, да это оно

                    Only users with full accounts can post comments. Log in, please.