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)

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

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

Сынок, за 15 лет что я проглю параллельные задачи ни разу :)

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

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

Вы таки разберитесь как устроен OpenMP и где там порождаются нити.

Чисто для справочки

ss@emachines-suse:~/Work/HyperFLOW3D-0.407Dev> cat *.cpp */*.cpp | grep «#pragma omp» | wc -l
89


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

>вы недостаточно осведомлены о фунциональных ЯП. С++ головного мозга

Срочно осведомите нас о ФЯП. Желательно на примере продуктов класса ANSYS

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

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

Ты вообще отличаешь лицензию от оси? Для тебя ubuntu, gentoo и slackware эквивалентны gpl, а freebsd эквивалентно bsd-лицензии. Красавчик, чо.

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

WTF фундаментальная математика?

Если идет речь о чистой математике, то где там там видел огромные формулы.

Как раз, в прикладной математике громоздкие формулы.

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

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

/0

Прикладная математика - это не два языка программирования.

Applied mathematics is a branch of mathematics that concerns itself with mathematical methods that are typically used in science, engineering, business, and industry.

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

Никак не могу найти омский словарь. Просто с обычным получается, что это ты херню нес. Ну так что - одолжишь омский словарик?

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

А есть альтернативы (свободные) ANSYS для моделирование движения жидкостей в емкостном оборудовании?

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

>А есть альтернативы (свободные) ANSYS для моделирование движения жидкостей в емкостном оборудовании?

Самая навороченная из альтернатив - OpenFOAM

ну и всякие Elmer, Code Saturne, Salome-MECA/Code_Aster

(а что такое «емкостное оборудование» ? бассейн с водой ? :) )

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

(а что такое «емкостное оборудование» ? бассейн с водой ? :))

И это тоже.

Реактора, кристаллизаторы, а также емкости (0,5, 0,7 и 1,0 дм^3).

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

Вообще если хотите поставить всё в одном флаконе то рекомендую вот этот вот дистрибутив линукса http://www.caelinux.com/

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

Вы путаете академические исследования коих был уже мильярд и продукты ынтырпрайз класса

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

> Вы путаете академические исследования коих был уже мильярд и продукты ынтырпрайз класса

Для того, чтобы выпускать продукты Ынтырпрайз класса, нужно вначале проделать исследования Ынтырпрайз класса. Все эти исследования проводят не от хорошей жизни. А что до Ынтырпрайза и функционалки, есть области, где она традиционно Ынтырпрайзно рулит (файненшл банкинг к примеру).

То, что сейчас нет хаскельно-эмельных АНСИС'ов, не говорит о неприменимости функционалки. Скорее о том, что многое в ней еще на стадии ресерча плюс программеры не готовы (не знают математики в той мере, в которой надо ее знать, просто не готовы сменить любимый инструмент на что-то новое и т.д.)

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

Статья кстати сама по себе интересная но есть одно но ...

как бы для сравнения из статьи:

Table I. Three test cases Test case 1 2 3 # mesh elements 120 180 300 # mesh nodes 287 427 671 # vertex nodes 84 124 186

И скажем к примеру моя текущая задача:

c 6 млн узлов распараллеленых на 76 ядер (вполне средняя задача)

700 узлов это вообще ниочём

Собственно посмотрите на дату издания. Это голос из могилы ФЯП в CFD

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

>Для того, чтобы выпускать продукты Ынтырпрайз класса, нужно вначале проделать исследования Ынтырпрайз класса.

Это уже 300 раз проделано. Пример тот же ANSYS

И было это уже очень давно. Ну и потом смешно говорить что «эти люди не знают математики»... У меня есть один знакомый аккустик который одно время работал с вышеупомянутыми людьми вместе в Imperial College а потом горбатился на Ролс&Ройс. У него тоже было хобби - ФЯП. Я его как то спросил - «Как насчёт перспектив использования ФЯП в CFD ?». На что он ответил что типа он ещё не ударился головой чтобы тащить ФЯП в CFD :))

Хотя с другой стороны посмотрите на язык представления задачи в OpenFOAM http://en.wikipedia.org/wiki/OpenFOAM

... но внутри у него всё те-же плюсы :))

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

> c 6 млн узлов распараллеленых на 76 ядер (вполне средняя задача)

А они там так и написали, hbcpp сильно прожорливый и потому юз кейс нормальный у них потестить не получилось. В моих задачах тоже цифры хорошие - 1.2 миллиарда распараллеленные на где-то 448 ядер. Там тоже плюсы трудятся, не функционалка.

Это уже 300 раз проделано. Пример тот же ANSYS

Это проделано в императивном мире. Зато в функциональном концепты растут как на дрожжах. Даже, казалось бы, простой как дерево зиппер был придуман не так давно.

Ну и потом смешно говорить что «эти люди не знают математики»

Средний программер не знает математику на нормальном уровне :) Да и математика разная бывает, кто-то интегралы с производными учил, числа Рейнольдса и прочее, зато пропустил теорию категорий.

У меня есть один знакомый аккустик который одно время работал с вышеупомянутыми людьми вместе в Imperial College а потом горбатился на Ролс&Ройс. У него тоже было хобби - ФЯП. Я его как то спросил - «Как насчёт перспектив использования ФЯП в CFD ?». На что он ответил что типа он ещё не ударился головой чтобы тащить ФЯП в CFD :))

И правильно говорит, потому и нужны исследования :)

Хотя с другой стороны посмотрите на язык представления задачи в OpenFOAM

А это мохоже на стандартный SIMD DSL, как, например Renderman SL

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

В документации значится, что нити порождаются один раз, а дальше этот пул используется повторно. Мой опыт это подтверждает - практически линейный рост производительности. Конечно, на соответствующем алгоритме (полностью независимые вычисления).

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

Это круто, но где .NET под открытой лицензией? Со всеми потрохами? Вот это был бы подарок всему сообществу программистов планеты. Про Visual Studio молчу, как-нибудь к Eclipse бы .NET прикрутили...

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

Да, виноват. Не посмотрел. Ябл даже для трёх языков постарался. Иногда и от них польза есть.

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

А у меня другой опыт. При попытке распараллеливать _много_ циклов из _различного_ числа итераций (1e2...1e7) OpenMP тормозит неимоверно. Тот же код с ручным управлением потоками (pthread, MPI) дает линейный рост производительности от числа потоков (проверял на 8-ми ядерной машине).

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

>А у меня другой опыт. При попытке распараллеливать _много_ циклов из _различного_ числа итераций (1e2...1e7) OpenMP тормозит неимоверно. Тот же код с ручным управлением потоками (pthread, MPI) дает линейный рост производительности от числа потоков (проверял на 8-ми ядерной машине).

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

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

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

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

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

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

> Ненужно. Есть же Erlang.

Erlang как числодробилка медленный.

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