https://www.opennet.ru/openforum/vsluhforumID3/79798.html Компания Intel объявила (http://software.intel.com/en-us/articles/intel-cilk-plus-open-source/) об открытии исходных текстов проекта "Cilk Plus (http://software.intel.com/en-us/articles/intel-cilk-plus-specification/)". В рамках проекта реализован набор расширений для языков Си и Си++ с реализации новой эффективной методики параллельного программирования, позволяющий существенно упростить разработку программ, части которых выполняются параллельно с задействованием разных процессорных ядер.<br><br><br>Одновременно, на основе кода Cilk Plus и набора компиляторов GCC 4.7 создана ветка cilkplus (http://gcc.gnu.org/svn/gcc/branches/cilkplus), которая может быть использована разработчиками GCC для упрощения интеграции Cilk Plus в состав основной ветки GCC. Компания Intel заявила, что ищет пути сотрудничества с разработчиками открытого ПО, как в плане развития исходных текстов, так и в направлении усовершенствования спецификаций Cilk Plus, которые распространяются в соответствии с принципами откры...<br><br>URL: http://softwar https://www.opennet.ru/openforum/vsluhforumID3/79798.html#29 Fri, 19 Aug 2011 20:07:10 GMT Компилятор не может распараллелить эффективно, ибо эти тонкости слабо зависят от процессора, а в основном зависят от ОС. Компилятор не знает достаточно данных о природе алгоритма и данных над которыми он оперирует. Си, и любой другой язык, недостаточно формализуют процесс с логической стороны (оно и не нужно, иначе будет слишком нудно кодить) чтобы можно было делать серьёзные трансформации исходного алгоритма.<br><br>с учётом знаний особенности процессора можно только эффективно использовать SIMD и RISC- подобные особенности. Но это эффективная векторизация (или сериализация), а не распараллеливание задания.<br> https://www.opennet.ru/openforum/vsluhforumID3/79798.html#28 Fri, 19 Aug 2011 06:40:05 GMT А в clang'е этого ждать стоит?<br> https://www.opennet.ru/openforum/vsluhforumID3/79798.html#27 Thu, 18 Aug 2011 22:45:19 GMT &gt;и правильно, просто эффективнее самому забить параллельность алгоритм чем отдавать решение на усмотрение автоматики.<br><br>Наоборот, компилятор знает особенности процессора на очинь низком уровне, и может распараллелить с учетом этой информации. Особеннно на VLIW и прочих человеконенавистнических железках. В этом то и была главная идея OpenMP, почитатйте. А то что сейчас это практически пускалки пулов это просто времени маловато, сам алгоритм оптимизации сложный. <br> https://www.opennet.ru/openforum/vsluhforumID3/79798.html#26 Thu, 18 Aug 2011 16:42:23 GMT &gt; Компания Intel заявила, что ищет пути сотрудничества с разработчиками открытого ПО<br><br>Так и открыла бы ICC, тем самым, ускорив это свободное ПО процентов на 20 сходу.<br> https://www.opennet.ru/openforum/vsluhforumID3/79798.html#25 Thu, 18 Aug 2011 13:48:04 GMT &gt; Что до C - то там, во-первых, вышеуказанная запись не годится, так как массив в C не знает свой размер<br><br>в ряде случаев знает. Есть массивы с явным указанием размера, можно сделать тип с фиксированным колв-ом элементов в массиве.<br><br>&gt; То есть придётся писать что-то вроде a[:n]. <br><br>ну и слайсы тоже полезны, типа [n:m], для них размер не важен. Плюс от слайсов в оптимизации с помощью simd, в опенпм такого нет.<br><br>&gt; C - это всё же кросс-платформенный ассемблер, который должен делать четко контролируемые вещи. <br><br>нее... это си минус такой. В общем, вопрос не такой однозначный с нужностью слайсов.<br><br>&gt; Даже то же OpenMP там мало где применяется ... скорее явно работают с пулами процессов.<br><br>и правильно, просто эффективнее самому забить параллельность алгоритм чем отдавать решение на усмотрение автоматики.<br> https://www.opennet.ru/openforum/vsluhforumID3/79798.html#23 Thu, 18 Aug 2011 06:40:28 GMT Будет, только в обратную сторону =)<br> https://www.opennet.ru/openforum/vsluhforumID3/79798.html#22 Wed, 17 Aug 2011 21:31:25 GMT &gt; а чем мы заменаем а openmp операции с массивами? типа a[:] = 1.0 и т.п.<br><br>Честно сказать, я вот сразу так и не вспомню прикладную задачу<br>в которой необходима выборка произвольного элемента массива. <br><br>Только какие-нибудь случайные матрицы. <br><br>---<br><br>Вспомнился кусок из кодека VP8, там много работы с массивами.<br>Да и то, линейные закономерности видны. <br> <br> https://www.opennet.ru/openforum/vsluhforumID3/79798.html#20 Wed, 17 Aug 2011 20:18:28 GMT Да, этого нет, и я это помянул чуть выше в качестве плюса/минуса по сравнению с OpenMP. <br>Но здеь есть пара нюансов. В C++ это тривиально решается на уровне библиотек без расширения языка (нет никаких проблем переопределить операторы для std::vector, к примеру) - и, соотвтественно, в плюсах эта система никогда принята не будет. Что до C - то там, во-первых, вышеуказанная запись не годится, так как массив в C не знает свой размер. То есть придётся писать что-то вроде a[:n]. Во-вторых - для C это конструкции не самого подходящего уровня. C - это всё же кросс-платформенный ассемблер, который должен делать четко контролируемые вещи. Даже то же OpenMP там мало где применяется - численные расчёты делаются (с ним же) на фортране, в остальном - скорее явно работают с пулами процессов.<br><br>Вот в каком-нибудь питоне, джаваскрипте и подобных высокоуровневых примитивных языках эта штука подошла бы, пожалуй ;-) А в не примитивных хочется иметь при необходимости больший контроль над распараллеливанием.<br> https://www.opennet.ru/openforum/vsluhforumID3/79798.html#19 Wed, 17 Aug 2011 18:39:05 GMT OpenMP вообще не образец сложности ни разу - там всей спецификации десяток страниц. Если человек это не способен освоить, то в программировании ему делать нечего.<br>