Компания Intel объявила (http://software.intel.com/en-us/articles/intel-cilk-plus-ope.../) об открытии исходных текстов проекта "Cilk Plus (http://software.intel.com/en-us/articles/intel-cilk-plus-spe.../)". В рамках проекта реализован набор расширений для языков Си и Си++ с реализации новой эффективной методики параллельного программирования, позволяющий существенно упростить разработку программ, части которых выполняются параллельно с задействованием разных процессорных ядер.
Одновременно, на основе кода Cilk Plus и набора компиляторов GCC 4.7 создана ветка cilkplus (http://gcc.gnu.org/svn/gcc/branches/cilkplus), которая может быть использована разработчиками GCC для упрощения интеграции Cilk Plus в состав основной ветки GCC. Компания Intel заявила, что ищет пути сотрудничества с разработчиками открытого ПО, как в плане развития исходных текстов, так и в направлении усовершенствования спецификаций Cilk Plus, которые распространяются в соответствии с принципами откры...URL: http://software.intel.com/en-us/articles/intel-cilk-plus-ope.../
Новость: http://www.opennet.me/opennews/art.shtml?num=31517
Они изобрели OpenMP!
> Они изобрели OpenMP!Вот именно. Почему это не интегрировать в OpenMP - непонятно.
Видимо обьяснить ддолжно название поста в блоге - Parallelism as a First Class Citizen in C and C++
Так реализация на вид идентична OpenMP - никак не более first class. Ну вместо pragma omp parallel пишем _Cilk_spawn - велика ли разница?
читал хоть что они предлагают? там расширение с/++, а не костыли вроде препроцессора на openmp
> читал хоть что они предлагают? там расширение с/++, а не костыли вроде
> препроцессора на openmpПримитивное оно, честно говоря. В отличие от OpenMP, где контроля много больше. В плюсах - array syntax, в минусах - он же, так как в отличие от OpenMP, которое включается и выключается ключом компилятора эта штука с самого начала требует принятия решения - хочешь ли ты параллельность. Что же касается spawn/sync/for - там я вообще никких преимуществ пред OpenMP не вижу.
> Примитивное оно, честно говоря. В отличие от OpenMP, где контроля много больше....
> никких преимуществ пред OpenMP не вижу.Вы сами упомянули главное преимущество - оно примитивное, поэтому им очень просто начать пользоваться и адаптировать под него уже написанный код.
Так OpenMP можно ровно так же использовать. Но при надобности запросто делаются более сложные вещи.
К примеру, в одном случае мы for заменяем на cilk_for, а в другом - перед ним пишем
#pragma omp parallel forcilk_spawn(func);
меняется на
#pragma omp parallel
func();насчёт sync на память не помню, но тоже тривиальная конструкция. А вот когда захочется, к примеру, ограничить количество задействованных потоков, или указать, что к какой-то переменной доступ надо делать последовательный - вот тут с OpeMP просто добавляется ещё строчка или параметр к parallel, а что делать с этим cilk в том виде, в каком оно сейчас - не знаю.
а чем мы заменаем а openmp операции с массивами? типа a[:] = 1.0 и т.п.
Да, этого нет, и я это помянул чуть выше в качестве плюса/минуса по сравнению с OpenMP.
Но здеь есть пара нюансов. В C++ это тривиально решается на уровне библиотек без расширения языка (нет никаких проблем переопределить операторы для std::vector, к примеру) - и, соотвтественно, в плюсах эта система никогда принята не будет. Что до C - то там, во-первых, вышеуказанная запись не годится, так как массив в C не знает свой размер. То есть придётся писать что-то вроде a[:n]. Во-вторых - для C это конструкции не самого подходящего уровня. C - это всё же кросс-платформенный ассемблер, который должен делать четко контролируемые вещи. Даже то же OpenMP там мало где применяется - численные расчёты делаются (с ним же) на фортране, в остальном - скорее явно работают с пулами процессов.Вот в каком-нибудь питоне, джаваскрипте и подобных высокоуровневых примитивных языках эта штука подошла бы, пожалуй ;-) А в не примитивных хочется иметь при необходимости больший контроль над распараллеливанием.
> Что до C - то там, во-первых, вышеуказанная запись не годится, так как массив в C не знает свой размерв ряде случаев знает. Есть массивы с явным указанием размера, можно сделать тип с фиксированным колв-ом элементов в массиве.
> То есть придётся писать что-то вроде a[:n].
ну и слайсы тоже полезны, типа [n:m], для них размер не важен. Плюс от слайсов в оптимизации с помощью simd, в опенпм такого нет.
> C - это всё же кросс-платформенный ассемблер, который должен делать четко контролируемые вещи.
нее... это си минус такой. В общем, вопрос не такой однозначный с нужностью слайсов.
> Даже то же OpenMP там мало где применяется ... скорее явно работают с пулами процессов.
и правильно, просто эффективнее самому забить параллельность алгоритм чем отдавать решение на усмотрение автоматики.
>и правильно, просто эффективнее самому забить параллельность алгоритм чем отдавать решение на усмотрение автоматики.Наоборот, компилятор знает особенности процессора на очинь низком уровне, и может распараллелить с учетом этой информации. Особеннно на VLIW и прочих человеконенавистнических железках. В этом то и была главная идея OpenMP, почитатйте. А то что сейчас это практически пускалки пулов это просто времени маловато, сам алгоритм оптимизации сложный.
Компилятор не может распараллелить эффективно, ибо эти тонкости слабо зависят от процессора, а в основном зависят от ОС. Компилятор не знает достаточно данных о природе алгоритма и данных над которыми он оперирует. Си, и любой другой язык, недостаточно формализуют процесс с логической стороны (оно и не нужно, иначе будет слишком нудно кодить) чтобы можно было делать серьёзные трансформации исходного алгоритма.с учётом знаний особенности процессора можно только эффективно использовать SIMD и RISC- подобные особенности. Но это эффективная векторизация (или сериализация), а не распараллеливание задания.
> а чем мы заменаем а openmp операции с массивами? типа a[:] = 1.0 и т.п.Честно сказать, я вот сразу так и не вспомню прикладную задачу
в которой необходима выборка произвольного элемента массива.Только какие-нибудь случайные матрицы.
---
Вспомнился кусок из кодека VP8, там много работы с массивами.
Да и то, линейные закономерности видны.
OpenMP вообще не образец сложности ни разу - там всей спецификации десяток страниц. Если человек это не способен освоить, то в программировании ему делать нечего.
> Так как в библиотеке совсем не много специфичного для архитектур
> x86_32 и x86_64 кода, такое портирования не составит труда.Если всё так просто, то почему Интел сам этого не сделал, в перерывах между перекурами ?
Потому что интелу эти архитектуры не интересны. Ваш К.О.
наверно, Intel не любит своих конкурентов (ARM и т.д.) и хочет оставить их с багами.
А чем это произведение отличется от включенного в gcc кода graphite? или graphite только оптимизирует код, но не распаралеливает?
оно только для интел камней или будет и на амд работать?
Будет, только в обратную сторону =)
> Компания Intel заявила, что ищет пути сотрудничества с разработчиками открытого ПОТак и открыла бы ICC, тем самым, ускорив это свободное ПО процентов на 20 сходу.
А в clang'е этого ждать стоит?