KirillM 26 июл 2010 в 11:46

Распараллеливание рекурсивных функций, используя OpenMP 3.0 task

3 мин

13K

Блог компании Intel

+16

Комментарии 21

Vetal4eg 26 июл 2010 в 19:12

Флаг России в первой табличке сразу добавил патриотизму прочтению (:

Labinskiy 26 июл 2010 в 20:15

Спасибо, очень интересный опыт.

denim 26 июл 2010 в 20:29

что то не могу понять что такое Intel® Composer XE. это Intel C++ Compiler или какой то другой продукт? запутался я в интеловский маркетинговых ходах. ну и небольшая ремарка: сравнивать то конечно полезно, но за gcc не просят денег.

KirillM 26 июл 2010 в 20:44

Composer XE == Compiler Pro v.12. Только, теперь не будет 12-й версии будет продукт под названием Intel® C++/Fortran Composer XE. В которой входят (как компоненты) Intel® C++/Fortran Compiler, Intel® TBB, IPP и MKL. Так же есть продукт Intel® Parallel Composer(не эквивалентно Intel® Composer XE), который является компонентой Intel® Parallel Studio.

denim 26 июл 2010 в 22:28

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

denim 26 июл 2010 в 22:29

software.intel.com/en-us/forums/showthread.php?t=70955

SoM 26 июл 2010 в 20:30

Спасибо за проделанную работу! Полезные цифры!

lega 26 июл 2010 в 20:41

Core i7, какая из моделей использовалась в тесте?

tyomitch 26 июл 2010 в 21:52

Фибоначчи — неинтересный, нерепрезентативный пример, т.к. практически нет общих данных между тасками.
Сложности с параллелизацией возникают во-многом из-за общих данных, их блуждания между кэшами и т.п.

gribozavr 26 июл 2010 в 22:46

Почему не включали оптимизацию при компиляции? Оверхед кода без оптимизации может быть совершенно разным у двух компиляторов, и возможно вы сравнили не реализации OpenMP, а оверхед от отсутстивия оптимизации.

KirillM 26 июл 2010 в 23:12

Я ставил перед собой задачу: понять как правильно применять таски в рекурсиях. По умолчанию многие опции компилятора(в том числе и оптимизации) активны. К примеру, у Intel® Compilers –O2 и –xSSE2 для Linux. Можно и руками все заанролить. Про какую именно оптимизацию идет речь?

gribozavr 26 июл 2010 в 23:28

Вот, а в gcc по умолчанию -O0. Таким образом при использовании приведённых в статтье параметров код gcc будет заведомо медленнее кода icc.

KirillM 27 июл 2010 в 00:16

Пересчитал, на X5560 с опциями GCC –O2 –msse2, дабы уровнять уровни оптимизации с Intel® Composer XE. Результаты следующие: 98.17 сек (1 поток), 60.66 сек (2 потока), 38.46 сек (4 потока), 23.77 сек (8 потоков) и 14.74 (16 потоков).
В результате, видно, что с GCC расчет происходит быстрее на одном потоке. Но картина относительно масштабируемости не изменилась: Для GCC 4.5.0 эффективность распараллеливания ~0.5 до тех пор, пока количество потоков не превышает количества физических ядер.

gribozavr 27 июл 2010 в 01:59

Только что запустил для n=50 на i5-750, gcc 4.4.4:

1 поток — 68.19 сек
2 потока — 42.07 сек
3 потока — 42.64 сек (!)
4 потока — 28.54 сек

Возникает вопрос: почему на 1 и на 2 потоках i5 быстрее всех представленных в топике процессоров?

Ваши бинарники запустить не смог, 404.

Я убрал ненужный task в main() и получил 37.21 сек на 3 потоках (остальные результаты равны в пределах погрешности).

Во всех случаях видно, что планировщик OpenMP в gcc вообще не использует четвертое ядро при 4 потоках.

Но, если заинлайнить fib() один раз саму в себя:

 #pragma omp task shared( i1 ) untied

 i1 = fib( n - 2 );

 #pragma omp task shared( i2 ) untied

 i2 = fib( n - 3 );

 #pragma omp task shared( j1 ) untied

 j1 = fib( n - 3 );

 #pragma omp task shared( j2 ) untied

 j2 = fib( n - 4 );

 #pragma omp taskwait

 return i1 + i2 + j1 + j2;

то 4 ядра используются, но коэффициент ускорения всё-равно только 3.0.