Я думаю, что модель Cilk является вложенной задача параллелизм (который вы можете использовать для реализации
параллелизм данных). Это довольно мило, но ...
Cilk не поддерживает параллелизм данных SIMD или потоковый параллелизм.
Похоже, что Cilk плохо справляется с частичными заказами по задачам, потому что он предлагает только вложенный параллелизм. Попробуйте кодировать следующий набор параллельных задач: A, B, C, D с ограничениями порядка A перед B, A перед D, C перед D. (Это канонический пример наименьшего частичного порядка задач, который параллелизм вложенных задач не может закодировать напрямую). Вы теряете некоторый параллелизм, реализуя это с помощью вложенного параллелизма. Параллелизм ценен, вы не хотите упускать возможности быть параллельными.
Он не обрабатывает (AFAIK) обработку исключений через границы потоков.
Это необходимо, если вы хотите создать действительно большое, сложное символическое приложение.
Это также полезно, если вы хотите рассчитать умозрительно.
Я также не думаю, что Cilk может обрабатывать большие наборы взаимодействия (в ожидании событий синхронизации) между частями вычислений, потому что AFAIK в программе Cilk может иметь только столько живых параллельных вычислений, сколько существует потоков, предлагаемых ОС. Это связано с тем, что реализация Cilk основана на стандартных компиляторах C / C ++ и их стековых моделях, которые на большинстве рабочих станций используют модель «один большой стек на поток». Вы можете получить до 10 или 100, но не до 10 000; это важно при работе с очень большими графиками. [Я точно не знаю, что Cilk даже позволяет синхронизировать вычислительные зерна, но я не вижу никаких технических причин, почему это не удалось бы, если бы он отказался от модели с большим стеком].
Вторым следствием является то, что приложения Cilk не могут обрабатывать огромные структуры данных, потому что любой размер стека ограничен, и есть некоторый пример, для которого вам не хватит стека. (Это не недостаток дизайна Cilk, просто его реализация). Это очень плохо, потому что огромные вещи - это одно из мест, где вам нужен параллелизм.
В качестве альтернативы см. PARLANSE , который предлагает
произвольно большое количество вычислительных зерен, с кражей работы, но с выделенными кучей зернами и записями активации. Каждое зерно имеет свой собственный контекст (и, следовательно, можно реализовать большие взаимодействующие наборы зерен, потому что просто сохранить состояние зерна, когда нужно ждать события. Примитивы синхронизации PARLANSE включают в себя фьючерсы, семафоры и результаты критических функций (см. Ниже). )
PARLANSE предлагает явные «команды» (набор вычислительных гранул) в качестве абстракции, с исключениями, распространяющимися из функций в начало вычислительного зерна (Java определяет это как «неопределенное», что глупо), для родителя команды обратно ко всем остальным дочерним элементам команды как асинхронное исключение прерывания (перехватываемое в предложении try), позволяющее другим дочерним элементам выполнять очистку.
Поскольку некоторые действия (например, асинхронные исключения прерывания) могут происходить в произвольные моменты времени, PARLANSE предлагает понятие критических функций , результаты которых гарантированно будут возвращены вызывающей стороне атомарно, поэтому функция либо возвращает результат гарантированно или нет, и функция может безопасно очистить ресурсы в обработчике прерывания асинхронного выполнения.
Специальные команды «частичного порядка» позволяют кодировать вычисления, в которых известен частичный порядок; Я думаю, что это более эффективно, чем вложенный параллелизм Cilk, если у вас есть большие наборы таких.
(Мы используем PARLANSE для реализации инструментов для анализа / преобразования крупномасштабных программ. . PARLANSE был изобретен для поддержки этого; нам нужен параллелизм, потому что артефакты, с которыми мы имеем дело, - это огромные, ну, деревья и графики, представляет миллионы строк кода).
(PARLANSE также не выполняет потоков или SIMD, но они не выходят за рамки языка. Можно добавить потоки и SIMD в C и C ++, но, вероятно, это будет довольно сложно).