В списке рассылки разработчиков LLVM представлен (http://lists.cs.uiuc.edu/pipermail/llvmdev/2011-October/0442...) проект Portable OpenCL (https://launchpad.net/pocl), в рамках которого ведётся разработка полностью открытой и независимой реализации стандарта OpenCL (http://www.khronos.org/opencl/), который определяет API и расширения языка Си для параллельного программирования с использованием как многоядерных CPU, так и GPU видеокарт.Задача проекта - создать единую реализацию OpenCL, независимую от производителей графических ускорителей, которая позволила бы разработчикам не задумываться об особенностях той или иной реализации стандарта и применении специфических техник оптимизации. Для этого Portable OpenCL реализован по модульному принципу, позволяющему использовать различные бэкенды для выполнения OpenCL-ядер на разных типах графических и центральных процессоров. Пока проект находится в стадии активной разработки, поэтому доступен только один бэкенд, поддерживающий использо...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/2011-October/0442...
Новость: http://www.opennet.ru/opennews/art.shtml?num=32092
Зашевелились, и это хорошо. Даже steckdenis обновил свой проект после долгой паузы http://cgit.freedesktop.org/~steckdenis/clover/commit/?id=c3...
На ЛОРе в обсуждении новости кто-то высказал интересную мысль. Благодаря свободной реализации OpenCL во всех дистрибутивах будет библиотека OpenCL сразу. Как сейчас /usr/lib/libGL.so.1: во всех дистрибутивах свободная Mesa, которую сразу все удаляют, заменяя на проприетарную версию. Программы затем имеют зависимость от libGL.so.1 и работают во всех дистрибутивах, даже где проприетарных видеодрайверов нет. А с Portable OpenCL программа запустится без nvidia cuda tooltit или amd stream sdk, имея необязательную использованную опцию OpenCL.А моё мнение: будет что привязывать к открытому драйверу radeon.
Необязательно используемую
http://code.google.com/p/freeocl/
"Задача проекта - создать единую реализацию ... которая позволила бы разработчикам не задумываться о ... применении специфических техник оптимизации"Спасибо. Вот чего не хватало, так это создания проектов по продвижению неоптимизированных кодов. Хотя после IM на гиг я уже ничему не удивляюсь.
> создания проектов по продвижению неоптимизированных кодовВообще-то речь как раз о том, чтобы не дублировать одни и те же оптимизации для каждой отдельной реализации. А то, понимешь, наизобретали велосипедов.
2.9
NVidia не так давно тоже заявляла нечто подобное, только для именно CUDA. - Чтобы с каждой новой реализацией ее видеокарт становились не нужны особые оптимизационные техники. Что видно, в принципе, даже уже давно, по версиям Compute Capability - в более новых версиях отпадает необходимость в части оптимизаций.
Я бы сказал иначе: рост производительности техники сокращает разницу выполнения оптимального и неоптимального кода на незагруженной аппаратуре. Проще купить проц следующего поколения чем потратить полчаса на оптимизацию. Особенно это становится явным при использовании модульного подхода, когда задачей многих становится собрать из кубиков-модулей своё мега-творение и продать его, при этом не неся ответственности ни за один из компонентов.
В случае с CUDA не учет расположения банков памяти на GPU влечет замедление работы в разы. Практически такая же картина при любых техниках/технологиях работы с многопоточностью - не учет факторов, влияющих на оптимизацию выполнения - замедляет работу программы иногда и в десятки раз (а в случае блокировок программа вообще никогда нормально не завершится). :)Неудача Висты была вызвана как раз неправильными какими-то вещами в работе многопоточного кода, я подробности не помню, но когда вышла 7-ая виндовс - была информация от разработчиков, с переводом в Рунете, что реально повлияло на неудачу Висты.
Они там что, прикалываются?! Кому opencl на x86 сдался? Програминг opencl напоминает полную йогу и имеет смысл в ровно 1 случае: скорость любой ценой. Даже ценой йоги, нужной лишь потому что gpu - не cpu, полновесный си с очень параллельными simd равсширениями в него втолкать тяжко. А такое урезанное и специализированное - запросто. Программить в таком виде х86? Зачем???
Для отладки. Одно дело теория, а другое дело просто поменать ключик компилятора или выбрать в выппадающем списке программы другой драйвер в ревлтайме и погладеть как оно на самом деле работает. А то написать "наша программа (или очередная железка)за $10000 в 30 раз быстрее CPU" может каждый, а тут клик клик - и сравниваем реально.