Хабр Курсы для всех
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 13
Я думаю что в ближайшем будущем (лет через 5 скорее всего) появится имплементация виртуальной машины Java которая будет использовать OpenCL для ускорения исполнения виртуального кода что вполне теоритически возможно
Меня всегда улыбает фраза "… появится имплементация виртуальной машины Java которая ...".
В HotSpot влиты просто огромные количества человеко-лет. Java является самой распространенной промышленной платформой отчасти благодаря своей предсказуемости. Даже версия от IBM, не смотря на свои возраст, стабильность и всякие RT ништяки занимает небольшой сегмент рынка.
В HotSpot влиты просто огромные количества человеко-лет. Java является самой распространенной промышленной платформой отчасти благодаря своей предсказуемости. Даже версия от IBM, не смотря на свои возраст, стабильность и всякие RT ништяки занимает небольшой сегмент рынка.
в Android-е появился Renderscript
конечно это что-то вроде связки Java+JavaCL (это не JVM-CL), но желание опробовать (и вложиться во что-то) новое от Google похвально
конечно это что-то вроде связки Java+JavaCL (это не JVM-CL), но желание опробовать (и вложиться во что-то) новое от Google похвально
Вряд ли это возможно в текущем виде реализации технологии OpenCL. Она приминима лишь к определенному кругу задач, есть границы применимости связанные с особенностью аппаратного обеспечения. Мне кажется перспективным в ближайшие годы — реализация части алгоритмов с java коллекциями на OpenCL по аналогии со ScalaCL и реализация fork-join фреймворка с использованием java closure которые транслируются в OpenCL функции по аналогии с проектом Aparapi. Также отлично вписываются в технологию задачи обработки/фильтрации изображений java2D/JAI. Но JAI похоже умер так и не родившись, по крайней мере опыт работы с ним оставил неприятные воспоминания(
Не думаю, что «появится имплементация виртуальной машины 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.
AMD — активно продвигает OpenCL
NVIDIA — продвигает OpenCL, но так же продвигает и CUDA. Основная ставка на CUDA
Intel CPU — поддерживает OpenCL, но смысла в этом нет, т.к. люди привыкли программировать по другому да и архитектурно оно сильно отличается от GPU
Intel MIC — неясно что с поддержкой OpenCL, основной позыв на директивы
Таким образом, появление данной виртуальной машины будет работать только на AMD, либо их будет несколько для AMD, NVIDIA, Intel.
Вы правы Насчет аппаратных особенностей и оптимизации алгоритма под конкренные платформы.
Разработка оптимальных с точки зрения производительности 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 я описал свое мнение в комментарии выше)
Разработка оптимальных с точки зрения производительности 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 я описал свое мнение в комментарии выше)
Проект 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.
А человеку минусов наставили.
Как-то затих этот проект. По крайней мере идея в основе sumatra отличная. Сложность реализации этого проекта достаточно высокая.
Под капотом там не OpenCL, некий промежуточный код HSA, в который скоро будет транслироваться и OpenCL. И такой технологии в jvm есть на платформах с поддержкой Shared Virtual Memory
Под капотом там не OpenCL, некий промежуточный код HSA, в который скоро будет транслироваться и OpenCL. И такой технологии в jvm есть на платформах с поддержкой Shared Virtual Memory
кстати,
если в статье заменить Java на .NET/Mono, а JavaCL на Cloo(есть в OpenTK)/OpenCL.NET,
то статью с тем же успехом и выводами можно читать и приверженцам .NET :)
если в статье заменить Java на .NET/Mono, а JavaCL на Cloo(есть в OpenTK)/OpenCL.NET,
то статью с тем же успехом и выводами можно читать и приверженцам .NET :)
Может кто знает как называется чип от Nvidia на платформе ARM?
Спасибо, да это оно
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Разработка на Java и OpenCL: Дорога в облака