MPI для многоядерных?

Question

С недавним слухом о многоядерном программировании кто-нибудь изучает возможности использования MPI ?

Answer 1

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

MPI является стандартом де-факто для крупномасштабных научных вычислений, и он уже широко используется на многоядерных машинах. Это очень быстро. Посмотрите на последний список 500 лучших . Лучшие машины в этом списке имеют, в некоторых случаях, сотни тысяч процессоров с многоядерными двух- и четырехъядерными узлами. Многие из этих машин имеют очень быстрые пользовательские сети (Torus, Mesh, Tree и т. Д.) И оптимизированные реализации MPI, которые знают об оборудовании.

Если вы хотите использовать MPI с одноядерным многоядерным компьютером, он будет работать нормально. Фактически, последние версии Mac OS X поставляются с предустановленной OpenMPI , и вы можете безболезненно загрузить установочный OpenMPI на обычную многоядерную машину с Linux. OpenMPI используется в Лос-Аламос на большинстве их систем. Ливермор использует mvapich в своих кластерах Linux. Перед погружением стоит помнить, что MPI был разработан для решения крупномасштабных научных задач в системах с распределенной памятью . Многоядерные блоки, с которыми вы имеете дело, вероятно, имеют разделяемую память .

OpenMPI и другие реализации по умолчанию используют общую память для локальной передачи сообщений, поэтому вам не нужно беспокоиться о сетевых затратах при передаче сообщений локальным процессам. Это довольно прозрачно, и я не уверен, где другие плакаты получают свои опасения по поводу высоких накладных расходов. Предостережение заключается в том, что MPI - не самая легкая 1022 * вещь, которую вы могли бы использовать для получения параллелизма на одном многоядерном блоке. В MPI вся передача сообщений является явной. По этой причине он был назван "ассемблером" параллельного программирования. Явная связь между процессами не проста, если вы не опытный HPC человек, и есть другие парадигмы, более подходящие для общей памяти ( UPC , OpenMP и хорошие языки, такие как Erlang и другие), которые вы можете попробовать в первую очередь.

Мой совет - использовать MPI, если вы планируете написать параллельное приложение, для решения которого может потребоваться более одной машины. Вы сможете тестировать и нормально работать с обычным многоядерным процессором, и миграция в кластер будет довольно безболезненной, как только вы его там заработаете. Если вы пишете приложение, которое когда-либо будет нуждаться только в одной машине, попробуйте что-нибудь другое. Существуют более простые способы использования такого параллелизма.

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

Answer 2

Я бы согласился с Тгамблином. Вероятно, вам придется засучить рукава и по-настоящему копаться в коде, чтобы использовать MPI, явно обрабатывая организацию передачи сообщений самостоятельно. Если это то, что вам нравится или не против, я думаю, что MPI будет работать на многоядерных машинах так же хорошо, как на распределенном кластере.

Говоря из личного опыта ... Я написал код C в аспирантуре, чтобы провести крупномасштабное моделирование электрофизиологических моделей в кластере, где каждый узел сам был многоядерной машиной. Поэтому для решения этой проблемы я подумал о нескольких параллельных методах.

1) Я мог бы использовать только MPI, рассматривая каждый процессор как свой собственный "узел", даже если некоторые из них сгруппированы на одной машине.

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

Для конкретной математической задачи, над которой я работал, я проверил две формулировки сначала на одной многоядерной машине: одну с использованием MPI и одну с использованием потоков POSIX. Как оказалось, реализация MPI была намного более эффективной, что дало ускорение, близкое к 2, для двухъядерной машины, а не 1,3-1,4 для многопоточной реализации. Для кода MPI я смог организовать операции так, чтобы процессоры редко находились в режиме ожидания, оставаясь занятыми, пока между ними передавались сообщения, и маскировали большую часть задержки при передаче данных. Благодаря многопоточному коду я столкнулся с множеством узких мест в мьютексах, которые заставляли потоки часто сидеть и ждать, пока другие потоки завершат свои вычисления. Сохранение балансировки вычислительной нагрузки между потоками не помогло этому факту.

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

Answer 3

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

Когда вы используете механизм блокировки, накладные расходы на мьютекс плохо масштабируются. это связано с тем, что подчеркивающая очередь выполнения не знает, когда вы собираетесь заблокировать поток следующим. Используя мьютекс, вы будете выполнять больше действий на уровне ядра, чем шаблон проектирования передачи сообщений.

Answer 4

Нет, по моему мнению, это не подходит для большинства процессов, которые вы выполняете в многоядерной системе. Слишком высокие накладные расходы, объекты, которые вы проходите, должны быть глубоко клонированы, а передача больших графов объектов для выполнения очень маленьких вычислений очень неэффективна. Он действительно предназначен для совместного использования данных между отдельными процессами, чаще всего выполняемыми в отдельных пространствах памяти и чаще всего выполняющими длинные вычисления.
Многоядерный процессор - это машина с разделяемой памятью, поэтому есть гораздо более эффективные способы параллельной обработки, которые не включают в себя копирование объектов и когда большинство потоков выполняется очень мало времени. Например, подумайте о многопоточной быстрой сортировке. Затраты на выделение памяти и копирование данных в поток, прежде чем они будут разбиты, будут намного медленнее при использовании MPI и неограниченного числа процессоров, чем Quicksort, работающий на одном процессоре. Например, в Java я бы использовал BlockingQueue (конструкция разделяемой памяти) для передачи объекта ссылок между потоками с очень небольшими издержками.
Не то, чтобы у него не было своего места, смотрите, например, поисковый кластер Google, который использует передачу сообщений. Но это, вероятно, не та проблема, которую вы пытаетесь решить.

Answer 5

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

Answer 6

MPI имеет очень большие накладные расходы, в основном для обработки межпроцессного взаимодействия и гетерогенных систем. Я использовал его в тех случаях, когда передается небольшой объем данных и когда отношение вычислений к данным велико. Это не типичный сценарий использования для большинства потребительских или бизнес-задач, и в любом случае, как упоминалось в предыдущем ответе, в архитектуре с общей памятью, такой как многоядерная машина, существуют гораздо более быстрые способы ее обработки, например указатели памяти. 1001 *

Если у вас возникли какие-то проблемы со свойствами, описанными выше, и вы хотите иметь возможность распространять работу на другие машины, которые должны быть в той же высокоскоростной сети, что и вы, тогда, возможно, MPI может иметь смысл. Мне трудно представить такой сценарий.

Answer 7

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

Я использовал несколько пакетов OSS для (C и C ++), которые можно масштабировать и оптимизировать планирование задач. TBB (многопоточные строительные блоки) и Cilk Plus хороши и просты в кодировании и получают практическое применение. Я также полагаю, что они достаточно гибки, чтобы интегрировать в него другие технологии потоков, если понадобится позже (OpenMP и т. Д.)

www.threadingbuildingblocks.org www.cilkplus.org