| |
| 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 - велика ли разница?
| | |
|
|
| |
| 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 +/– | |
> Примитивное оно, честно говоря. В отличие от OpenMP, где контроля много больше.
...
> никких преимуществ пред OpenMP не вижу.
Вы сами упомянули главное преимущество - оно примитивное, поэтому им очень просто начать пользоваться и адаптировать под него уже написанный код.
| | |
| |
| 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 в том виде, в каком оно сейчас - не знаю.
| | |
| |
| |
| 7.20, Crazy Alex (ok), 00:18, 18/08/2011 [^] [^^] [^^^] [ответить]
| +/– |
Да, этого нет, и я это помянул чуть выше в качестве плюса/минуса по сравнению с OpenMP.
Но здеь есть пара нюансов. В C++ это тривиально решается на уровне библиотек без расширения языка (нет никаких проблем переопределить операторы для std::vector, к примеру) - и, соотвтественно, в плюсах эта система никогда принята не будет. Что до C - то там, во-первых, вышеуказанная запись не годится, так как массив в C не знает свой размер. То есть придётся писать что-то вроде a[:n]. Во-вторых - для C это конструкции не самого подходящего уровня. C - это всё же кросс-платформенный ассемблер, который должен делать четко контролируемые вещи. Даже то же OpenMP там мало где применяется - численные расчёты делаются (с ним же) на фортране, в остальном - скорее явно работают с пулами процессов.
Вот в каком-нибудь питоне, джаваскрипте и подобных высокоуровневых примитивных языках эта штука подошла бы, пожалуй ;-) А в не примитивных хочется иметь при необходимости больший контроль над распараллеливанием.
| | |
| 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.7, arzeth (ok), 15:39, 17/08/2011 [^] [^^] [^^^] [ответить]
| +1 +/– |
 наверно, Intel не любит своих конкурентов (ARM и т.д.) и хочет оставить их с багами.
| | |
|
| 1.8, кто здесь (?), 16:02, 17/08/2011 [ответить] [﹢﹢﹢] [ · · · ]
| +1 +/– |
А чем это произведение отличется от включенного в gcc кода graphite? или graphite только оптимизирует код, но не распаралеливает?
| | |
| 1.26, maxkit (ok), 20:42, 18/08/2011 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
 > Компания Intel заявила, что ищет пути сотрудничества с разработчиками открытого ПО
Так и открыла бы ICC, тем самым, ускорив это свободное ПО процентов на 20 сходу.
| | |
|
