Комментарии 31
Подсчет чисел Фибоначчи — далеко не лучший пример для демонстрационного параллельного приложения. Хотя в академических кругах его любят.
Cilk+ — это не новый язык, это расширение языков С/С++ с помощью компилятора. По сути, тоже самое что и openmp.
Поддержка Cilk+ есть в GCC 4.7. Или тут: software.intel.com/en-us/articles/intel-cilk-plus/
Cilk+ — это не новый язык, это расширение языков С/С++ с помощью компилятора. По сути, тоже самое что и openmp.
Поддержка Cilk+ есть в GCC 4.7. Или тут: software.intel.com/en-us/articles/intel-cilk-plus/
+6
>Подсчет чисел Фибоначчи — далеко не лучший пример для демонстрационного параллельного приложения. Хотя в академических кругах его любят.
А почему?
А Cilk+ и Cilk это немного разные вещи, насколько я знаю. Cilk+ это последствие покупки и коммерциализации Cilk'а Intel'ом. Да, оба они являются надстройками над С, но вроде такие вещи принято называть языками.
А почему?
А Cilk+ и Cilk это немного разные вещи, насколько я знаю. Cilk+ это последствие покупки и коммерциализации Cilk'а Intel'ом. Да, оба они являются надстройками над С, но вроде такие вещи принято называть языками.
+2
Потому что самый лучший алгоритм для них не паралеллится.
+1
Параллелится, просто не на уровне потоков. SIMD для умножения матриц — тоже параллелизм.
0
На самом деле я поторопился, для больших чисел (когда умножение становится не атомарной операцией) прекрасно параллелится. Если я конечно правильно помню, что быстрые алгоритмы перемножения можно распараллелить:)
0
Алгоритм Карацубы как минимум неплохо параллелится
0
Да, поскольку он сводит задачу к нескольким меньшим. Что позволит достаточно быстро загрузить столько потоков, сколько захотим.
Но алгоритм Шёнхаге-Штрассена использует быстрое преобразование Фурье, про которое уже нетривиально сказать, параллелится оно или нет.
Впрочем, википедия утверждает, что есть и еще лучше по асимптотике алгоритмы. С которыми мне разбираться, честно говоря, не хочется:)
Но алгоритм Шёнхаге-Штрассена использует быстрое преобразование Фурье, про которое уже нетривиально сказать, параллелится оно или нет.
Впрочем, википедия утверждает, что есть и еще лучше по асимптотике алгоритмы. С которыми мне разбираться, честно говоря, не хочется:)
0
Если совсем Cilk, то тут: supertech.csail.mit.edu/cilk/ — в параграфе software всегда лежит последняя версия.
Плохой — потому что рекурсия.
Если рассматривать работу приведенного алгоритма в терминах абсолютного параллелизма — все ок. Треды создаются — под них всегда есть место, они живут счастливо и им не тесно.
В системе с ограниченными ресурсами все станет грустно. Огребем постоянное переключение контекстов и наше параллельное приложение будет работать в разы меделеннее последовательной реализации. Решается это ограничением уровня вложенности.
Ну и алгортим приведенный — не лучший с точки зрения подсчета — многие вычисления дублируются по много десятков раз.
Плохой — потому что рекурсия.
Если рассматривать работу приведенного алгоритма в терминах абсолютного параллелизма — все ок. Треды создаются — под них всегда есть место, они живут счастливо и им не тесно.
В системе с ограниченными ресурсами все станет грустно. Огребем постоянное переключение контекстов и наше параллельное приложение будет работать в разы меделеннее последовательной реализации. Решается это ограничением уровня вложенности.
Ну и алгортим приведенный — не лучший с точки зрения подсчета — многие вычисления дублируются по много десятков раз.
+2
Для Cilk — это как раз очень хороший пример. Показывает, насколько эффективно система умеет создавать и обрабатывать задачи.
0
НЛО прилетело и опубликовало эту надпись здесь
для начала software.intel.com/en-us/articles/intel-cilk-plus/
В GCC 4.7 не пробовал, но выше говорят что поддержка есть, значит можно.
В GCC 4.7 не пробовал, но выше говорят что поддержка есть, значит можно.
0
Приведенный нет — там ключевые слова другие: _Cilk_spawn, _Cilk_sync, и _Cilk_for
В остальном все аналогично.
В остальном все аналогично.
+2
НЛО прилетело и опубликовало эту надпись здесь
Будет в одной из следующих статей.
Также планируется рассказать про GPU и CUDA.
Также планируется рассказать про GPU и CUDA.
+2
Cilk++
OpenMP
PS И не надо спавнить оба треда — достаточно одного. Так будет быстрее.
long fib_parallel(long n)
{
long x, y;
if (n < 2) return n;
x = cilk_spawn fib_parallel(n-1);
y = fib_parallel(n-2);
cilk_sync;
return (x+y);
}
OpenMP
long fib_parallel(long n)
{
long x, y;
if (n < 2) return n;
#pragma omp task default(none) shared(x,n)
{
x = fib_parallel(n-1);
}
y = fib_parallel(n-2);
#pragma omp taskwait
return (x+y);
}
PS И не надо спавнить оба треда — достаточно одного. Так будет быстрее.
+6
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
Написать параллельное приложение, нагружающее процессор хотя на все 4 ядра и при этом, работающее медленнее, чем однопоточное, совсем не проблема. Какое у вас приложение? Например, если распараллеливать очень мелкие задачи, которые быстро считаются, накладные расходы на блокировки могут снизить скорость вычислений.
0
Не понимаю зачем было так усложнять первую часть…
Если одна двадцатая часть (под)программы не параллелится, то больше чем в двадцать раз ускорить всю (под)программу нельзя, как ни старайся выполнять параллельно.
Если одна двадцатая часть (под)программы не параллелится, то больше чем в двадцать раз ускорить всю (под)программу нельзя, как ни старайся выполнять параллельно.
+1
Автор, по вашим формулам при распределении f=5%, граничный либо максимальный фактор ускорения 20, а просто фактор ускорения (без слов граничный, максимальный) зависит от количества ядер по вашим же формулам. И для 20 ядер при f=5% он будет чуть больше 10, а никак не 20.
0
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Ускорения параллельных вычислений