Scientific Computing :: OpenMP или Pthreads

Question

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

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

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

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

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

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

Этот является общим вопросом, посколькухорошо.

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

Answer 1

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

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

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

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

Answer 2

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

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

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

Разработка:

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

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

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

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

Answer 3

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