Scientific Computing :: OpenMP или Pthreads

Question

Я разрабатываю коды для научного компьютерного сообщества, особенно для решения линейной системы уравнений (Ax = b form) итеративно.

Я использовал BLAS и LAPACK для примитивных матричных подпрограмм, но теперь я понимаю, что есть несколько возможностей для ручной распараллеливания. Я работаю над системой общей памяти, которая оставляет меня с двумя вариантами: OpenMP и PThreads.

Предполагая, что время не является наибольшим фактором (& производительность кода), что является лучшим, будущим доказательством и, возможно, переносным (для CUDA) способом распараллеливания? Время, затрачиваемое на использование Pthreads, должно повысить производительность?

Я считаю, что мое приложение (которое в основном имеет дело со стартом сразу нескольких вещей, а затем работает с «лучшим» значением от всех них), выиграет от явного управления потоками, но я боюсь, что кодирование будет занимать слишком много времени, и в конце не будет никакой окупаемости.

Я уже рассмотрел несколько подобных вопросов здесь, но все они относятся к общим приложениям.

This один относится к универсальному многопоточному приложению в Linux.

This - общий вопрос.

Я знаю SciComp.SE, но чувствовал, что здесь больше по теме.

Answer 1

Ваш вопрос читается так, как если бы вы ожидали, что эффективность кодирования с помощью OpenMP будет выше, чем у Pthreads, а эффективность выполнения выше с Pthreads, чем с OpenMP. В общем, я думаю, что ты прав. Однако некоторое время назад я решил, что мое время было более важным, чем время моего компьютера, и выбрал OpenMP. Это не решение, о котором я сожалел, и это не решение, которое я могу подтвердить.

Однако вы ошибаетесь, полагая, что ваш выбор ограничен OpenMP и Pthreads, MPI (я предполагаю, что вы хотя бы слышали об этом, пост снова, если нет) также будет работать на компьютерах с общей памятью. Для некоторых приложений MPI может быть запрограммирован для того, чтобы без труда преодолеть OpenMP на компьютерах с общей памятью.

Три (+/- несколько) лет назад основными инструментами параллелизации в панели инструментов научного разработчика были OpenMP и MPI. Любой, кто использует эти инструменты, был частью большого сообщества других пользователей, более крупных (только для некоторых свидетельств), чем сообщество пользователей Pthreads и MPI. Сегодня, когда GPU и другие ускорители появляются повсюду, ситуация намного фрагментирована, и трудно выбрать одного из победителей из HMPP, ACC, Chapel, MPI-3, OpenMP4, CUDA, OpenCL и т. Д. Я все еще думаю что OpenMP + MPI - полезная комбинация, но не может игнорировать новых детей на блоке.

FWIW Я работаю над разработкой вычислительных кодов ЭМ для геофизических приложений, поэтому достаточно сложно «научными вычислениями».

Answer 2

Я понимаю, что мой ответ довольно долго, поэтому я ставлю заключение первого для нетерпеливых:

Короткий ответ:

Я бы сказал, OpenMP и Pthreads, по существу, то же самое, и вы должны выберите, какой из них потребует наименьшего времени для вас (возможно, openMP, если он соответствует вашим потребностям).Но если вы хотите инвестировать время разработки, возможно, вы должны перепроектировать свой код, чтобы он мог адаптироваться к другим парадигмам (например, векторизация, чтобы использовать SSE/AVX или графические процессоры).

развития:

Если вы разрабатываете линейные решатели, я полагаю, ваш код будет (очень) долгоживущий (т.е. он будет, вероятно, переживет физические модели, которые будут использовать его). В таких условиях, особенно если у вас нет большой команды разработчиков, я думаю, вы должны основывать свой выбор в первую очередь на времени разработки, ремонтопригодности и

Кроме того, вы не должны предполагать, что сегодня «лучший» выбор «лучший» может означать), вероятно, еще не будет «лучшим» выбором завтра. Итак, даже если вы столкнулись с проблемой openMP vs pthreads (и даже сейчас спектр уже больше, чем в ответе @ HighPerformanceMark), вы должны ожидать, что у вас будет больше альтернатив для выбора в будущем.

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

Это приводит меня к выводу: все поточно-ориентированные решения по существу эквивалентны (как с точки зрения производительности, так и с архитектурой кода), и вы должны выбрать любое решение, требующее наименьшего времени разработки. Но если вы хотите инвестировать время разработки, возможно, вы должны перепроектировать свой код, чтобы он мог быть либо распараллелен, либо векторизован (и, таким образом, использовать SSE/AVX или графические процессоры). Если вам удастся это сделать, вы сможете следить за развитием аппаратного и программного обеспечения и поддерживать производительность.

Answer 3

Чтобы добавить к уже отличным ответам: OpenMP обычно лучше выполняет распараллеливание моего кода, чем при записи pthreads. Учитывая, что OpenMP также проще, я всегда выбираю его, если это мои варианты. Я подозреваю, что если вы задаете этот вопрос, вы не являетесь гуру pthread, поэтому я также рекомендую использовать OpenMP поверх pthreads.