The OpenNET Project / Index page

[ новости/++ | форум | wiki | теги | ]

17.08.2011 13:50  Компания Intel представила ветку GCC с реализацией технологии Cilk Plus

Компания Intel объявила об открытии исходных текстов проекта "Cilk Plus". В рамках проекта реализован набор расширений для языков Си и Си++ с реализации новой эффективной методики параллельного программирования, позволяющий существенно упростить разработку программ, части которых выполняются параллельно с задействованием разных процессорных ядер.

Одновременно, на основе кода Cilk Plus и набора компиляторов GCC 4.7 создана ветка cilkplus, которая может быть использована разработчиками GCC для упрощения интеграции Cilk Plus в состав основной ветки GCC. Компания Intel заявила, что ищет пути сотрудничества с разработчиками открытого ПО, как в плане развития исходных текстов, так и в направлении усовершенствования спецификаций Cilk Plus, которые распространяются в соответствии с принципами открытых технологий.

В представленном коде реализованы три простых ключевых слова и специальная нотация для работы с массивами, которые позволяют быстро задействовать в приложениях на Си и Си++ возможности современных CPU, имеющих несколько процессорных ядер и векторные сопроцессоры (Vector Units). Для управления генерацией кода с улучшенной векторизацией предусмотрена pragma simd.

Поддерживается два метода увеличения производительности - параллелизм данных и параллельное выполнение подпрограмм. В первом случае, обеспечиваются механизмы прозрачного распараллеливания типовых операций над массивами данных и автоматическое задействование SIMD-инструкций. Для организации параллелизма на уровне подпрограмм в обиход вводится три ключевых слова: _Cilk_spawn - запуск функции в параллельном режиме, _Cilk_sync - ожидание завершения параллельно выполняемой функции, и _Cilk_for - организация работы цикла в параллельном режиме.

При проведение тестирования на 16-ядерном CPU реализация метода Монте-Карло при использовании Cilk Plus показала прирост производительности в два раза, в случае задействования режима параллельной обработки данных, и в 11.6 раз при использовании режима выполнения параллельных задач.

Отдельно распространяется специальная runtime-библиотека Intel Cilk Plus, код которой открыт под лицензией BSD. Runtime-библиотека протестирована в Linux (теоретически нет никаких ограничений по использованию в других ОС) на системах с архитектурами x86_32 и x86_64. Представители Intel надеются, что при помощи сообщества удастся портировать runtime-компоненты и для других архитектур. Так как в библиотеке совсем не много специфичного для архитектур x86_32 и x86_64 кода, такое портирование не составит труда.

  1. Главная ссылка к новости (http://software.intel.com/en-u...)
Лицензия: CC-BY
Тип: К сведению
Ключевые слова: intel, parallel, gcc, cpp
При перепечатке указание ссылки на opennet.ru обязательно
Обсуждение Ajax/Линейный | Раскрыть все сообщения | RSS
 
  • 1.2, Аноним (-), 15:10, 17/08/2011 [ответить] [показать ветку] [···]    [к модератору]
  • +3 +/
    Они изобрели OpenMP!
     
     
  • 2.6, Crazy Alex (ok), 15:19, 17/08/2011 [^] [ответить]    [к модератору]
  • +/
    > Они изобрели OpenMP!

    Вот именно. Почему это не интегрировать в OpenMP - непонятно.

     
     
  • 3.9, fr0ster (ok), 17:18, 17/08/2011 [^] [ответить]    [к модератору]
  • +/
    Видимо обьяснить ддолжно название поста в блоге - Parallelism as a First Class Citizen in C and C++
     
     
  • 4.12, Crazy Alex (ok), 18:34, 17/08/2011 [^] [ответить]    [к модератору]
  • +/
    Так реализация на вид идентична OpenMP - никак не более first class. Ну вместо pragma omp parallel пишем _Cilk_spawn - велика ли разница?
     
  • 2.10, all_glory_to_the_hypnotoad (ok), 17:53, 17/08/2011 [^] [ответить]    [к модератору]
  • +1 +/
    читал хоть что они предлагают? там расширение с/++, а не костыли вроде препроцессора на   openmp
     
     
  • 3.14, Crazy Alex (ok), 18:48, 17/08/2011 [^] [ответить]    [к модератору]  
  • +/
    > читал хоть что они предлагают? там расширение с/++, а не костыли вроде
    > препроцессора на   openmp

    Примитивное оно, честно говоря. В отличие от OpenMP, где контроля много больше. В плюсах - array syntax,  в минусах - он же, так как в отличие от OpenMP, которое включается и выключается ключом компилятора эта штука с самого начала требует принятия решения - хочешь ли ты параллельность. Что же касается spawn/sync/for - там я вообще никких преимуществ пред OpenMP не вижу.

     
     
  • 4.16, Аноним (-), 22:24, 17/08/2011 [^] [ответить]     [к модератору]  
  • +1 +/
    Вы сами упомянули главное преимущество - оно примитивное, поэтому им очень п... весь текст скрыт [показать]
     
     
  • 5.17, Crazy Alex (ok), 22:36, 17/08/2011 [^] [ответить]    [к модератору]  
  • +/
    Так OpenMP можно ровно так же использовать. Но при надобности запросто делаются более сложные вещи.
    К примеру, в одном случае мы for заменяем на cilk_for, а в другом - перед ним пишем
    #pragma omp parallel for

    cilk_spawn(func);
    меняется на
    #pragma omp parallel
    func();

    насчёт sync на память не помню, но тоже тривиальная конструкция. А вот когда захочется, к примеру, ограничить количество задействованных потоков, или указать, что к какой-то переменной доступ надо делать последовательный - вот тут с OpeMP просто добавляется ещё строчка или параметр к parallel, а что делать с этим cilk в том виде, в каком оно сейчас - не знаю.

     
     
  • 6.18, all_glory_to_the_hypnotoad (ok), 22:38, 17/08/2011 [^] [ответить]    [к модератору]  
  • +/
    а чем мы заменаем  а openmp операции с массивами? типа a[:] = 1.0 и т.п.
     
     
  • 7.20, Crazy Alex (ok), 00:18, 18/08/2011 [^] [ответить]    [к модератору]  
  • +/
    Да, этого нет, и я это помянул чуть выше в качестве плюса/минуса по сравнению с OpenMP.
    Но здеь есть пара нюансов. В C++ это тривиально решается на уровне библиотек без расширения языка (нет никаких проблем переопределить операторы для std::vector, к примеру) - и, соотвтественно, в плюсах эта система никогда принята не будет. Что до C - то там, во-первых, вышеуказанная запись не годится, так как массив в C не знает свой размер. То есть придётся писать что-то вроде a[:n]. Во-вторых - для C это конструкции не самого подходящего уровня. C - это всё же кросс-платформенный ассемблер, который должен делать четко контролируемые вещи. Даже то же OpenMP там мало где применяется - численные расчёты делаются (с ним же) на фортране, в остальном - скорее явно работают с пулами процессов.

    Вот в каком-нибудь питоне, джаваскрипте и подобных высокоуровневых примитивных языках эта штука подошла бы, пожалуй ;-) А в не примитивных хочется иметь при необходимости больший контроль над распараллеливанием.

     
     
  • 8.25, all_glory_to_the_hypnotoad (ok), 17:48, 18/08/2011 [^] [ответить]    [к модератору]  
  • +/
    > Что до C - то там, во-первых, вышеуказанная запись не годится, так как массив в C не знает свой размер

    в ряде случаев знает. Есть массивы с явным указанием размера, можно сделать тип с фиксированным колв-ом элементов в массиве.

    > То есть придётся писать что-то вроде a[:n].

    ну и слайсы тоже полезны, типа [n:m], для них размер не важен. Плюс от слайсов в оптимизации с помощью simd, в опенпм такого нет.

    > C - это всё же кросс-платформенный ассемблер, который должен делать четко контролируемые вещи.

    нее... это си минус такой. В общем, вопрос не такой однозначный с нужностью слайсов.

    > Даже то же OpenMP там мало где применяется ... скорее явно работают с пулами процессов.

    и правильно, просто эффективнее самому забить параллельность алгоритм чем отдавать решение на усмотрение автоматики.

     
     
  • 9.27, anonymous (??), 02:45, 19/08/2011 [^] [ответить]    [к модератору]  
  • +/
    >и правильно, просто эффективнее самому забить параллельность алгоритм чем отдавать решение на усмотрение автоматики.

    Наоборот, компилятор знает особенности процессора на очинь низком уровне, и может распараллелить с учетом этой информации. Особеннно на VLIW и прочих человеконенавистнических железках. В этом то и была главная идея OpenMP, почитатйте. А то что сейчас это практически пускалки пулов это просто времени маловато, сам алгоритм оптимизации сложный.

     
     
  • 10.29, Дядя_Анан (?), 00:07, 20/08/2011 [^] [ответить]    [к модератору]  
  • +/
    Компилятор не может распараллелить эффективно, ибо эти тонкости слабо зависят от процессора, а в основном зависят от ОС. Компилятор не знает достаточно данных о природе алгоритма и данных над которыми он оперирует. Си, и любой другой язык, недостаточно формализуют процесс с логической стороны (оно и не нужно, иначе будет слишком нудно кодить) чтобы можно было делать серьёзные трансформации исходного алгоритма.

    с учётом знаний особенности процессора можно только эффективно использовать SIMD и RISC- подобные особенности. Но это эффективная векторизация (или сериализация), а не распараллеливание задания.

     
  • 7.22, AHAHAC (ok), 01:31, 18/08/2011 [^] [ответить]    [к модератору]  
  • +/
    > а чем мы заменаем  а openmp операции с массивами? типа a[:] = 1.0 и т.п.

    Честно сказать, я вот сразу так и не вспомню прикладную задачу
    в которой необходима выборка произвольного элемента массива.  

    Только какие-нибудь случайные матрицы.  

    ---

    Вспомнился кусок из кодека VP8, там много работы с массивами.
    Да и то, линейные закономерности видны.
      

     
  • 5.19, Crazy Alex (ok), 22:39, 17/08/2011 [^] [ответить]    [к модератору]  
  • +1 +/
    OpenMP вообще не образец сложности ни разу - там всей спецификации десяток страниц. Если человек это не способен освоить, то в программировании ему делать нечего.
     
  • 1.3, Аноним Ус (?), 15:14, 17/08/2011 [ответить] [показать ветку] [···]    [к модератору]  
  • +/
    > Так как в библиотеке совсем не много специфичного для архитектур
    > x86_32 и x86_64 кода, такое портирования не составит труда.

    Если всё так просто, то почему Интел сам этого не сделал, в перерывах между перекурами ?

     
     
  • 2.5, Crazy Alex (ok), 15:18, 17/08/2011 [^] [ответить]    [к модератору]  
  • +3 +/
    Потому что интелу эти архитектуры не интересны. Ваш К.О.
     
  • 2.7, arzeth (ok), 15:39, 17/08/2011 [^] [ответить]    [к модератору]  
  • +1 +/
    наверно, Intel не любит своих конкурентов (ARM и т.д.) и хочет оставить их с багами.
     
  • 1.8, кто здесь (?), 16:02, 17/08/2011 [ответить] [показать ветку] [···]    [к модератору]  
  • +1 +/
    А чем это произведение отличется от включенного в gcc кода graphite? или graphite только оптимизирует код, но не распаралеливает?
     
  • 1.11, TrSiD (ok), 18:21, 17/08/2011 [ответить] [показать ветку] [···]    [к модератору]  
  • +2 +/
    оно только для интел камней или будет и на амд работать?
     
     
  • 2.23, xxx (??), 10:40, 18/08/2011 [^] [ответить]    [к модератору]  
  • +/
    Будет, только в обратную сторону =)
     
  • 1.26, maxkit (ok), 20:42, 18/08/2011 [ответить] [показать ветку] [···]    [к модератору]  
  • +/
    > Компания Intel заявила, что ищет пути сотрудничества с разработчиками открытого ПО

    Так и открыла бы ICC, тем самым, ускорив это свободное ПО процентов на 20 сходу.

     
  • 1.28, Аноним (-), 10:40, 19/08/2011 [ответить] [показать ветку] [···]    [к модератору]  
  • +/
    А в clang'е этого ждать стоит?
     

     Добавить комментарий
    Имя:
    E-Mail:
    Заголовок:
    Текст:


      Закладки на сайте
      Проследить за страницей
    Created 1996-2018 by Maxim Chirkov  
    ДобавитьПоддержатьВебмастеруГИД  
    Hosting by Ihor