LINUX.ORG.RU

Intel открыл исходные тексты проекта Intel Cilk Plus

 , ,


0

1

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

Расширение Cilk Plus добавляет в язык С/С++ три ключевых слова - _Cilk_spawn, _Cilk_sync и _Cilk_for, - а также выражения для объявления массивов, указания компилятору, а также некоторые другие единицы языка. Кроме того, многие нововведения заметно упрощают и делают более понятным для разработчика процесс отладки многопоточной программы.

Уже существует ветка компилятора GCC 4.7 со встроенным Intel Cilk Plus, а также официальная библиотека времени исполнения.

Расширение основано на совместных научных разработках Intel и MIT, проводившихся около 20 лет назад. Открытая реализация технологии может быть легко добавлена в уже написанные приложения, в результате чего получается масштабируемая система, способная работать с высокой производительностью многопоточно на сотнях ядер.

Спецификация

>>> Подробности

★★★★★

Проверено: Shaman007 ()
Последнее исправление: Zhbert (всего исправлений: 1)

Intel божественна, как всегда

Un
()

Их послушать, так прямо решение всех проблем многопоточности. А на деле всё сводится к

три ключевых слова - _Cilk_spawn, _Cilk_sync и _Cilk_fo, - а также выражения для объявления массивов, указания компилятору, а также некоторые другие единицы языка

Zenom ★★★
()

если эта штука будет в базовой поставке к GCC и кодеры будут это юзать - это будет прекрасно, не openmp единым, как говорится...

nevar ★★
()
Ответ на: комментарий от nevar

Наоборот. OpenMp стандарт, а при использовании этих расширений программа станет не портабельна и будет собираться только gcc.

anonymous
()
Ответ на: комментарий от anonymous

Блин, имел в виду вообще компиляторы, а написал GCC. Всё верно.

nevar ★★
()

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

Интел на высоте. Интересно на каких семействах процессоров расширение будет работать (не будет ли проблем с процессорами AMD)?

Genuine ★★★
()

Позитивно. Интересно, в llvm запилят?

encyrtid ★★★★★
()

Зачем? Ведь есть прекрасное портируемое Mono c замечательными F# и его Async Workflows!

P.S. Шучу :) . Отличная новость!

Gluttton
()
Ответ на: комментарий от anonymous

> Holy Shit. Может рассказать парням про Erlang?

про его скорость работы?

aho
()

Ключевое слово этой «заметки про нашего мальчика» это easy

То бишь параллелизм на коленке для тупых

programmers typically do not need to restructure programs significantly in order to add parallelism.

практика показывает что параллельный код, полученный таким образом, мало того что сольёт все профиты на баръерах так ещё будет кишеть неочевидными локами и рейсами ... хотя significantly конечно можно понимать сильно по разному... :)

sS ★★★★★
()
Ответ на: комментарий от sS

Вот ведь интеля жгут :))

Intel Threading Building Blocks (TBB) has been the most popular library solution for parallelism for C++

sS ★★★★★
()

Таки я зря поднял у себя вычислительный кластер на openmpi и начал читать книжечки по MPI? Вот ж-а!

skvitek ★★★
()
Ответ на: комментарий от sS

>практика показывает что параллельный код, полученный таким образом, мало того что сольёт все профиты на баръерах так ещё будет кишеть неочевидными локами и рейсами ... хотя significantly конечно можно понимать сильно по разному... :)

_Cilk_spawn - запуск функции в параллельном режиме

_Cilk_sync - ожидание завершения параллельно выполняемой функции

«Сливание» или наоборот - профиты должны будут зависеть от грамотности оперирования Cilk-ом программистом.

По поводу

do not need to restructure programs significantly in order to add parallelism

я думаю они погрячились, т.к., для распараллеливания алгоритма -> программы еще потрудиться нужно

Genuine ★★★
()
Ответ на: комментарий от anonymous

> Наоборот. OpenMp стандарт, а при использовании этих расширений программа станет не портабельна и будет собираться только gcc.

OpenMP имеет сумашедшие накладные расходы и часто сводит на нет выйгрыш от распараллеливания. Пока, что лучше pthread с оптимизированным созданием/вызовом нитей ничего не придумано.

Интересно посмотреть насколько этот вариант pthread'у проигрывает...

abalakin ★★
()
Ответ на: комментарий от skvitek

>Таки я зря поднял у себя вычислительный кластер на openmpi и начал читать книжечки по MPI? Вот ж-а!

У тех же интелей есть Сluster OpenMP :)

... у них на самом деле много чего есть на эту тему (TBB тот же) и кстати отменного качества (та же интеловская MPI например)

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

Профи же давно уже выбрали себе струмент по размеру :)

sS ★★★★★
()
Ответ на: комментарий от abalakin

На мой взгляд, вы не поняли, что я хотел сказать. OpenMP стандарт, который поддерживается значительным числом компиляторов, без относительно того, его эффективности. Я сомневаюсь, что данные расширения быстро (если вообще когда-нибудь) попадут в другие компиляторы.

На счет эффективности pthreads, ничего сказать увы не могу.

anonymous
()

А чем плох обычный OpenMP?

Deleted
()
Ответ на: комментарий от anonymous

Функциональные ЯП бессмысленны и беспощадны. Т.е. как Фундаментальная математика: куча мощных формул на всё-про-всё, но IRL их использовать невозможно и потому применяют прикладную математику. А прикладная математика - это и есть C, C++ и их наследники.

mine
()
Ответ на: комментарий от abalakin

>OpenMP имеет сумашедшие накладные расходы

Вы просто не умеете их готовить :) (c)

Просто оно действительно немного сложнее чем просто влепить перед циклом

#pragma omp parallel for

sS ★★★★★
()
Ответ на: комментарий от sS

>Просто оно действительно немного сложнее чем просто влепить перед циклом

#pragma omp parallel for

Да ну? Я вот влепил по приколу эту строку в свой самописный трассировщик лучей, так оно ровно в 4 раза быстрее стало. На 4 ядрах.

anonymous
()
Ответ на: комментарий от mine

> как Фундаментальная математика: куча мощных формул на всё-про-всё, но IRL их использовать невозможно и потому применяют прикладную математику

Это в каком ПТУ так учат?

roof ★★
()
Ответ на: комментарий от mine

>А прикладная математика - это и есть C, C++ и их наследники

У вас ФАНБОЙ. Пройдите на ампутацию.

anonymous
()
Ответ на: комментарий от X-Pilot

если бы не было понятий интелектуальной собственности и авторского права, и копирование не называли воровством, то тогда BSD-подобные лицензии были бы более свободными. Но пока это не так, и свободная лицензия - это GPLv3

faska
()
Ответ на: комментарий от Harald

> а что, OpenMP не обертка над pthreads?

Скорее всего обертка, только обертка обертке рознь. В ряде случаев (много циклов по ходу вычислений) расходы на обертку (создание нитей) сравнимы с временем расчета. Наоборот, при «умном» использовании pthread этих расходов нет вообще.

Естественно я не говорю про код, который идеально распараллеливается — один внешний цикл для перебора вариантов.

abalakin ★★
()
Ответ на: комментарий от faska

> если бы не было понятий интелектуальной собственности и авторского права, и копирование не называли воровством, то тогда BSD-подобные лицензии были бы более свободными. Но пока это не так, и свободная лицензия - это GPLv3

Хорошая формулировка.

hobbit ★★★★★
()
Ответ на: комментарий от X-Pilot

В случае gcc, как и другим gpl-кодом, этот рантайм нельзя статически слинковать.

madcore ★★★★★
()

>Intel открыла исходные тексты проекта Cilk Plus, расширения С и С++

Расширение Cilk Plus добавляет в язык С/С++ три ключевых слова

Расширение основано на совместных научных разработках Intel и MIT, проводившихся около 20 лет назад

Прогресс такой прогресс :)

sched
()

Респект Intel, это очень хорошая новость. Рад, что не зажали технологию(как это сделал бы ябл, или тролли из редмонда:)). Хотя причина благотворительности возможно лежит тоже в экономической плоскости. Появится куча ПО, которое будет оптимизировано под много-ядерность. И начнут люди покупать супермногоядерные процессоры для нового ПО. Кому основной профит? Интелю конечно:)

lucentcode ★★★★★
()
Ответ на: комментарий от lucentcode

> Рад, что не зажали технологию(как это сделал бы ябл, или тролли из редмонда:)).

Иногда лучше сначала знать, а потом говорить :)
http://en.wikipedia.org/wiki/Grand_Central_Dispatch

Grand Central Dispatch (GCD) is a technology developed by Apple Inc. to optimize application support for systems with multi-core processors and other symmetric multiprocessing systems.[2] It is an implementation of task parallelism based on the thread pool pattern. It was first released with Mac OS X 10.6, and is also available with iOS 4.

The source code for the library that provides the implementation of GCD's services, libdispatch, was released by Apple under the Apache License on September 10, 2009.

anonymous
()

>_Cilk_spawn

_microSoft_ о_доб_ряет __такой СТИЛЬ (програм)мирования__

anonymous
()
Ответ на: комментарий от mine

Ты умудрился тремя предложениями сказать: «Я не могу в ФЯП. Я не могу в C. Я не могу в C++. Я не могу в математику. Я говорю про то, в чем не смыслю.»

anonymous
()
Ответ на: комментарий от faska

> если бы не было понятий интелектуальной собственности и авторского права, и копирование не называли воровством, то тогда BSD-подобные лицензии были бы более свободными. Но пока это не так, и свободная лицензия - это GPLv3

Вот из-за таких уродов и выпускают под анальной ГПЛ, которая разработчикам только мешает делать новые продукты на основе имеющихся. Большое вам спасибо.

anonymous
()
Ответ на: комментарий от lucentcode

> Рад, что не зажали технологию(как это сделал бы ябл, или тролли из редмонда:)).

Им эта разработка скорее всего на хер не нужна и они тупо надеятся, что хоть кто-нибудь из свободного сообщества заинтересуется. Своих-то ресурсов на такую хрень жалко.

anonymous
()
Ответ на: комментарий от anonymous

> Я вот влепил по приколу эту строку в свой самописный трассировщик лучей, так оно ровно в 4 раза быстрее стало. На 4 ядрах.

И чего? Да, есть программы, которые легко параллелятся с помощью OpenMP. Пачку таких можно глянуть в туториалах.

anonymous
()
Ответ на: комментарий от anonymous

Из-за таких уродов мы имеем ubuntu, gentoo и slackware. А вы имеете проститутку-bsd, которую уже все поимели и с удовольствием.

alx_me ★★☆
()

Я так понимаю, яблочный GCD и эта штука имеют смысл в основном для старого софта, который хочется быстро заставить работать чуть получше на современных процессорах. Поскольку переписать всё нереально, надо просто вдумчиво покурить над старым кодом и обьявить компилятору, что вот это и вот это можно делать параллельно. А новый софт нужно сразу писать с прицелом на многоядерность, с использованием хоть TBB, хоть голых pthreads, хоть ещё чего.

anonymous
()

Да чего они там открыли?

We have recently created a new branch for GCC-4.7 called «cilkplus» in which we have started implementing the Intel® Cilk™ Plus extensions

Our plan is to implement the full Intel Cilk Plus extension, as laid out in the Intel Cilk Plus Language Specification. This is the first release of an ongoing project

отсюда

Открывальщики знатные...

crimson_eyes
()
Ответ на: комментарий от sS

>кишеть неочевидными локами и рейсами ...

Ну и хардкодеры собрались. Операторы ещё не снятся?

anonymous
()
Ответ на: комментарий от anonymous

Сколько народу хлещет ягу и сколько хенеси ХО. Учись студент.

Lonli-Lokli ★★
()
Ответ на: комментарий от anonymous

>трассировщик лучей

так параллельные задачи этим не ограничиваются :)

Понятно что ваш hello world будет хорошо параллелиться ввиду специфики задачи. Есть задачи которые вот так вот просто эффективно распараллелить не получится.

sS ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.