Вы правы Насчет аппаратных особенностей и оптимизации алгоритма под конкренные платформы.
Разработка оптимальных с точки зрения производительности 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 я описал свое мнение в комментарии выше)
Да такой подход применим и для .NET/Mono и Cloo. Мой опыт разработки связан с jvm. Каждый кулик хвалит свое болото ;) Если напишите пост про опыт разработки Mono/Cloo + OpenCL под linux, с удовольствием почитаю.
Вряд ли это возможно в текущем виде реализации технологии OpenCL. Она приминима лишь к определенному кругу задач, есть границы применимости связанные с особенностью аппаратного обеспечения. Мне кажется перспективным в ближайшие годы — реализация части алгоритмов с java коллекциями на OpenCL по аналогии со ScalaCL и реализация fork-join фреймворка с использованием java closure которые транслируются в OpenCL функции по аналогии с проектом Aparapi. Также отлично вписываются в технологию задачи обработки/фильтрации изображений java2D/JAI. Но JAI похоже умер так и не родившись, по крайней мере опыт работы с ним оставил неприятные воспоминания(
Разработка оптимальных с точки зрения производительности 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 я описал свое мнение в комментарии выше)