Для каждого примера из папки example есть проект для XCode, правда шестилетней давности. Интересно, они только на интеловских процессорах пойдут или на Силиконе тоже?
Странная ссылка, вот правильная.
LVV>Кто-нить пользовался ?
Да, и прямо и опосредованно. Хорошая библиотека, ей уже много лет.
Есть и альтернативы, не менее популярные, например, taskflow.
Ну и с каждым стандартом всё ближе по функционалу подбирается openmp, но это намного, намного менее удобно.
Здравствуйте, Hоmunculus, Вы писали:
H>Для каждого примера из папки example есть проект для XCode, правда шестилетней давности. Интересно, они только на интеловских процессорах пойдут или на Силиконе тоже?
Здравствуйте, Nuzhny, Вы писали:
N>... N>Да, и прямо и опосредованно. Хорошая библиотека, ей уже много лет. N>Есть и альтернативы, не менее популярные, например, taskflow. N>Ну и с каждым стандартом всё ближе по функционалу подбирается openmp, но это намного, намного менее удобно.
Плюсую taskflow.
В интел всегда софтверная часть шла со скрипом, только с появлением itanium они стали серьёзно заниматься софтом. Ну и в нынешней ситуации они вряд ли будут что-либо активно развивать. Впрочем, tbb уже очень давно готов для продакшена.
Вообще где-то тут на форуме публиковали пропоузал о том, что в плюсах хотят унифицировать многопоточность — то есть сделать так, чтобы каждая либа не тянула за собой свою имплементацию тредпула. Увы, не слежу за этой темой, не знаю в каком оно статусе.
Здравствуйте, LaptevVV, Вы писали:
LVV>Кто-нить пользовался ?
Нам, в своё время, пытались продать. Но сразу сказали, что наилучшие результаты будут с их компилятором и на их-же процах (очевидно).
У нас не было бюджета на смену компилятора (мы только что стабилизировались после перехода на 64 бит), да и проверяли альтернативы Интелу (хотя, вот уже и до сих пор с ними).
Сама библиотека в наших узких местах не помогла из-за специфики. У нас много огромных картинок, на которые натравливаются алгоритмы. Картинки приходят строго одна за одной, и результат обработки должен быть в той-же последовательности. Разделить память картинки по шинам в многопроцессорных системах невозможно, библиотека показала худший результат по сравнению с нашим доморощенным параллелизмом.
Естественно они нам сказали, что у нас архитектура не та, и делаем мы всё не правильно.
Спрсоили совета как это надо сделать — они развели руками, и подарили нам профайлер.
Здравствуйте, LaptevVV, Вы писали:
LVV>Библиотека для параллельных вычислений.
LVV>Кто-нить пользовался ?
Знакомс. На корке клауда(likeof AWS) пользовался в проекте, где оказался я, основная фишка, почему он там оказался так фрилокнутых структурах данных (мапах, векторах, етц... )
Здравствуйте, ботаныч, Вы писали:
Б>Здравствуйте, LaptevVV, Вы писали:
LVV>>Библиотека для параллельных вычислений.
LVV>>Кто-нить пользовался ? Б> Знакомс. На корке клауда(likeof AWS) пользовался в проекте, где оказался я, основная фишка, почему он там оказался так фрилокнутых структурах данных (мапах, векторах, етц... )
т.е. lockfree containers etc...
П.С. не помню рассказывал нет, но попал я на проектик где индусы\китайцы каким-то макаром переманили одного из архов амазона (хранцуз-ф))) в свой клауд проект. Ну собсна там и пользовалась эта либа.
Здравствуйте, Nuzhny, Вы писали:
N>Здравствуйте, LaptevVV, Вы писали:
LVV>>Свободная: https://github.com/syncur/tbb
N>Странная ссылка, вот правильная.
LVV>>Кто-нить пользовался ?
N>Да, и прямо и опосредованно. Хорошая библиотека, ей уже много лет. N>Есть и альтернативы, не менее популярные, например, taskflow. N>Ну и с каждым стандартом всё ближе по функционалу подбирается openmp, но это намного, намного менее удобно.
opnenmp это совсем не сравнимо с tbb. Совсем другое, это из разряда std::prallel_foreach(begin, end, [](){ enum xz {x, z}; return x;}); просто в коде выглядит аля единый скоуп. tbb больше про
std::prallel_foreach(begin, end, [&map0, &map2](auto iter0, auto iter1){ replicate(iter0, iter1); );
в неблокирующих алгоритмах
Здравствуйте, ботаныч, Вы писали:
Б>opnenmp это совсем не сравнимо с tbb.
Не сравнимо по способу решения задач или по типу решаемых задач? По способу — согласен, но они оба предназначены для одного и того же, нет? Тем более, для openmp стандарты новые выходят, на месте не стоит.
Здравствуйте, Nuzhny, Вы писали:
N>Здравствуйте, ботаныч, Вы писали:
Б>>opnenmp это совсем не сравнимо с tbb.
N>Не сравнимо по способу решения задач или по типу решаемых задач? По способу — согласен, но они оба предназначены для одного и того же, нет? Тем более, для openmp стандарты новые выходят, на месте не стоит.
я где-то в 2020 раcпараллеливал один мат. алгоритм для автоматического дифaеренцирования (adjoint) c openmp. Openmp скорее расширение для компилятора, выделяется скоуп с помощью прагм, на параллельный или single thread, есть барьеры etc...
tbb, включает всевозможные мьютексы (рекурсивные, на объектах ядра), но в том проект, где я с этим работал основной момент был в lock free контейнерах. Этого я не помню в openmp, не пробовал иcпользовать стандартные атомики в openmp. скажем tbb для параллелизма полнее openmp, хотя #pragma omp parallel, #pragma omp for в чем-то проще. НЕт необходимости руками создавать пул потоков.
