[c] многонитевое (thread) программирование

> Правильно ли я понял, что мне надо копать в сторону openmp?

нет. openmp это узкая ниша, где компилятор автоматически распараллеливает циклы по твоим подсказкам. Некоторым этого достаточно, но отнюдь не всем.

> Правильно ли я понял, что мне надо копать в сторону openmp?

Posix threads.

У OpenMP есть ряд оговорок. Лично для себя я решил без надобности с ним не связыватся - надо учить синтаксис (он не такой уж и простой), поддержка в GCC только в последних - как результат, переносимость оставляет желать лучшего. Плюс - из уже запущенной нити OpenMP лучше не использовать - M$ рекомендует такое вообще не делать, с GCC результат тоже весьма плачевный (в стандартах эта тема вообще не раскрыта) - т.е. работать с OpenMP только из основного потока программы. Как результат - с GUI использование OpenMP затруднено.

IMHO, сделан был OpenMP чтобы улучшить продажи многоядерников, пока они ещё не проникли на десктопы.

P.S. в GCC OpenMP реализуется как вызовы runtime-library функций - всё это скрывается расширениями синтаксиса языка. В результате программа уже будет не совсем на C/C++ языке, а реального выигрыша перед pthreads по сути не будет.

>Posix threads.

Я так понимаю это то что мне нужно?

>> Posix threads.

> Я так понимаю это то что мне нужно?

Это зависит от того, что тебе на самом деле нужно :)

Да. В Linux'е (возможно, в FreeBDS и MacOSX тоже) они используются, в винде свой механизм - для кроссплатформенности лучше смотреть в сторону QT(C++) GTK/GLib (в GLib насколько помню тоже есть кросс-платформенные нити).

А по сути - оттуда тебе надо собственно нити (pthread_), атомарные типы (atomic_t), мьютексы и семафоры. Синхрить нити удобно семафорами (если надо распаралеленное вычисление в какой-то точке выполнения синхронизировать).

> для кроссплатформенности лучше смотреть в сторону QT(C++) GTK/GLib (в GLib насколько помню тоже есть кросс-платформенные нити).

В копилку: Boost.Threads.

Apache Portable Runtime

может лучше fork?

> надо учить синтаксис (он не такой уж и простой)


да, чего уж проще сказать
#pragma omp parallel for


Этого хватает в 99% случаев. Всякие private/shared в прагмах указывать нафиг не надо, достаточно правильно разнести объявления переменных по блокам внутри цикла.


> GCC только в последних - как результат, переносимость оставляет желать лучшего.


Если вдруг пускаешь на древности на которой не доступен gcc-4, то ничего страшного, все твои pragma будут пропущены, а код будет работать.


> Как результат - с GUI использование OpenMP затруднено.


еще бы, OpenMP заточен под числодробильню

> а реального выигрыша перед pthreads по сути не будет.

Да, так и представляю какую-нибудь линейную алгебру параллелить руками на pthread. В конце концов ты придешь к какому-нибудь велосипеду аналогичному openmp, только он будет выглядеть не так элегантно, так как будет состоять из нагромождений вызовов pthread и ручным разбиеним циклов по потокам, да и работать будет, естественно, медленнее.

Хм. Нужную тему поднял товарищ, как раз заинтересовался тем же. Только меня сперва заинтересовал теоретический аспект. Может кто-нибудь посоветовать литературу на тему как правильно распараллеливать вычисления? Можно без касательства к программированию

> Да, так и представляю какую-нибудь линейную алгебру параллелить руками на pthread. В конце концов ты придешь к какому-нибудь велосипеду аналогичному openmp, только он будет выглядеть не так элегантно, так как будет состоять из нагромождений вызовов pthread и ручным разбиеним циклов по потокам, да и работать будет, естественно, медленнее.

Ну, это ты немного преувеличил... На лин. алгебре pthreads работают так же быстро, как и OpenMP. Выглядит он при этом вполне элегантно со стороны вызова операций над векторами и матрицами, и совсем чуть-чуть менее элегантно внутри себя.

А вот как ты своё ручное разбиение матрицы по потокам в OpenMP сделаешь?

> Ну, это ты немного преувеличил... На лин. алгебре pthreads работают так же быстро, как и OpenMP. Выглядит он при этом вполне элегантно со стороны вызова операций над векторами и матрицами, и совсем чуть-чуть менее элегантно внутри себя.

Я этим занимаюсь и знаю о чем говорю. На openmp счетную программу пишешь как обычно, а распараллеливание получается практически бесплатно. Для pthread надо специально изначально затачивать программу. Кода получается в разы больше и его существенно сложнее отлаживать. Никто в здравом уме никогда не делает счетные программы на голом pthread.

На MPI и то кода меньше получается и проще отлаживаться. Поэтому если считают на SMP, то пишут ВСЕГДА на OpenMP, а на кластерах сейчас применяют гибридную технологию MPI+OpenMP.

> А вот как ты своё ручное разбиение матрицы по потокам в OpenMP сделаешь?

Зачем мне это делать руками? За меня это openmp лучше сделает.

Я тоже этим занимаюсь... И я специально сравнивал pthread и OpenMP. Разницы в скорости не заметил. Использовал ICC.

> Зачем мне это делать руками? За меня это openmp лучше сделает.

А зачем тогда METIS и прочая придуманы?

> Я тоже этим занимаюсь... И я специально сравнивал pthread и OpenMP. Разницы в скорости не заметил. Использовал ICC.

Естественно в идеале разницы в скорости не будет. А какова сложность написания/отладки этого хозяйства и какой объем кода? Еще раз повторю, что на OpenMP распараллеливание делается практически бесплатно.

> А зачем тогда METIS и прочая придуманы?

Первый раз слышу. Что это такое ? Была еще какая-то вещь, которую делали на мехмате tcc кажется, но оно так и не прижилось у народа.

http://glaros.dtc.umn.edu/gkhome/views/metis Гугл рулит...

Объём кода для реализации параллельности весьма небольшой. Буквально пара-тройка классов. В тысячу строк легко укладывается. Со всеми абстракциями, кроссплатформенностью, планировщиком задач и прочая...

Отладка сильно упрощается при использовании Intel Thread Checker и Intel Thread Profiler.

В тысячу строк можно поместить достаточно серьезный алгоритм с уже готовым распараллеливанием на openmp.

На первый взгляд либа сложная и заточена на реализацию алгоритмов специального вида. Где там классический пример умножения матрицу не вектор?

Там уножения нету... Да и, не такое уж и сложное дело распараллелить это самое умножение. Гораздо интереснее распараллелить ILU с отбрасыванием по норме элементов больше чем на 2 потока. А ещё интересней, чтобы при этом ещё и пресловутое умножение сбалансированным оказалось...

> еще бы, OpenMP заточен под числодробильню

оригинальный вопрос был про мультитридинг, а не числодробление - так что я и описал тонкости (недостатки) OpenMP с позиции мультитридинга, а не числодробления.

Если тебе полностью подходит OpenMP - то используй, бога ради.