MPI для многоядерных процессоров?

Ответ 1

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

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

Если вы хотите использовать MPI с одночиповой многоядерной машиной, она будет работать нормально. Фактически, последние версии Mac OS X поставляются с OpenMPI предварительно установленным, и вы можете без проблем загружать установку OpenMPI на обычном многоядерном Linux. OpenMPI используется в Los Alamos для большинства своих систем. Livermore использует mvapich в своих кластерах Linux. Что нужно помнить до погружения, так это то, что MPI был разработан для решения широкомасштабных научных проблем в системах с распределенной памятью. Многоядерные коробки, с которыми вы имеете дело, вероятно, имеют общую память.

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

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

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

Ответ 2

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

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

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

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

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

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

Ответ 3

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

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

Ответ 4

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

Ответ 5

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

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

Ответ 6

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

Ответ 7

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

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

www.threadingbuildingblocks.org www.cilkplus.org