Comments 13
Я думаю что в ближайшем будущем (лет через 5 скорее всего) появится имплементация виртуальной машины Java которая будет использовать OpenCL для ускорения исполнения виртуального кода что вполне теоритически возможно
-4
Меня всегда улыбает фраза "… появится имплементация виртуальной машины Java которая ...".
В HotSpot влиты просто огромные количества человеко-лет. Java является самой распространенной промышленной платформой отчасти благодаря своей предсказуемости. Даже версия от IBM, не смотря на свои возраст, стабильность и всякие RT ништяки занимает небольшой сегмент рынка.
В HotSpot влиты просто огромные количества человеко-лет. Java является самой распространенной промышленной платформой отчасти благодаря своей предсказуемости. Даже версия от IBM, не смотря на свои возраст, стабильность и всякие RT ништяки занимает небольшой сегмент рынка.
+2
в Android-е появился Renderscript
конечно это что-то вроде связки Java+JavaCL (это не JVM-CL), но желание опробовать (и вложиться во что-то) новое от Google похвально
конечно это что-то вроде связки 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.
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 я описал свое мнение в комментарии выше)
Разработка оптимальных с точки зрения производительности 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
Под капотом там не OpenCL, некий промежуточный код HSA, в который скоро будет транслироваться и OpenCL. И такой технологии в jvm есть на платформах с поддержкой Shared Virtual Memory
0
кстати,
если в статье заменить Java на .NET/Mono, а JavaCL на Cloo(есть в OpenTK)/OpenCL.NET,
то статью с тем же успехом и выводами можно читать и приверженцам .NET :)
если в статье заменить Java на .NET/Mono, а JavaCL на Cloo(есть в OpenTK)/OpenCL.NET,
то статью с тем же успехом и выводами можно читать и приверженцам .NET :)
-3
Может кто знает как называется чип от Nvidia на платформе ARM?
0
Спасибо, да это оно
0
Sign up to leave a comment.
Articles
Change theme settings
Разработка на Java и OpenCL: Дорога в облака