MPI или сокеты?
Вызывающая сторона выдвигает аргументы в обратном порядке, в соответствии с x86 ABI, затем вызывает fun. Инструкция call помещает eip в стек перед переходом к fun. Затем вы устанавливаете свой кадр стека, делая ebp вершиной стека, поэтому arg1 должен быть на 8 байт выше кадра стека:
higher mem
+----------+---------+
| arg 3 | 4 bytes | push arg 3
+----------+---------+ (ebp + 16)
| arg 2 | 4 bytes | push arg 2
+----------+---------+ (ebp + 12)
| arg 1 | 4 bytes | push arg 1
+----------+---------+ (ebp + 8)
| ret addr | 4 bytes | call fun
+----------+---------+ (ebp + 4)
| old ebp | 4 bytes | push ebp; mov ebp, esp
+----------+---------+ <-------- (ebp + 0) STACK FRAME START
lower mem
10 ответов
MPI МОГ БЫ использовать сокеты. Но существует также реализация MPI, которая будет использоваться с SAN (Системная сеть), которые используют прямую распределенную общую память. Это, конечно, если у Вас есть аппаратные средства для этого. Таким образом, MPI позволяет Вам использовать такие ресурсы в будущем. На том случае можно получить крупные повышения производительности (на моем опыте с кластерами назад в университетское время, можно достигнуть усилений нескольких порядков величины). Таким образом, если Вы пишете код, который может быть портирован к кластерам более высокого уровня, использование MPI является очень хорошей идеей.
Даже отбрасывание проблем производительности, с помощью MPI может сохранить Вас много времени, которое можно использовать, чтобы улучшить производительность других частей системы или просто сохранить исправность.
Я рекомендовал бы использовать MPI вместо того, чтобы прокрутить Ваше собственное, если Вы не очень хороши в такой вещи. Наличие записало некоторые приложения распределенных-вычислений-esque с помощью моих собственных протоколов, я всегда воспроизвожу (и плохо воспроизвести) функции, найденные в MPI.
Производительность, мудрая, я не ожидал бы, что MPI даст Вам любые материальные сетевые ускорения - это использует сокеты точно так же, как Вы. MPI однако предоставит Вам очень функциональность, в которой Вы нуждались бы для управления многими узлами, т.е. синхронизацией между узлами.
Передача сообщений является парадигмой не технология. В самой общей установке MPI будет использовать сокеты для передачи. Вы видели скорость путем переключения на MPI, но только поскольку Вы не оптимизировали свою связь с сокетом.
Как является Вашим приложением связанный ввод-вывод? Это привязано передача блоков данных к узлам работы, или это связывается из-за коммуникации во время вычисления?
Если ответ "из-за коммуникации" затем, проблема - Вы, пишут приложение с сильной связью и пытаются выполнить его на кластере, разработанном для слабо связанных задач. Единственный способ получить производительность будет состоять в том, чтобы получить лучшие аппаратные средства (более быстрые переключатели, infiniband, и т.д.)..., возможно, Вы могли одолжить время на чужом HPC?
Если ответ является передачами "блока данных", затем считают присваивающихся рабочих несколькими блоками данных (таким образом, они остаются занятыми дольше), и сожмите блоки данных перед передачей. Это - стратегия, которая может помочь в слабо связанном приложении.
В этом случае производительность не является единственным фактором, даже на высокопроизводительных кластерах. MPI предлагает стандартный API и является «переносимым». Относительно тривиально переключать приложение между различными версиями MPI.
Большинство реализаций MPI используют сокеты для связи на основе TCP. Скорее всего, любая реализация MPI будет лучше оптимизирована и обеспечит более быструю передачу сообщений, чем собственное приложение, использующее сокеты напрямую.
Кроме того, если у вас когда-нибудь появится возможность запустить свой код в кластере с InfiniBand, уровень MPI будет абстрагировать любое из этих изменений кода. Это не тривиальное преимущество - кодирование приложения для непосредственного использования реализации OFED (или другого глагола IB) очень сложно.
Большинство приложений MPI включают небольшие тестовые приложения, которые можно использовать для проверки правильности настройки сети независимо от вашего приложения. Это большое преимущество, когда приходит время отладки вашего приложения. Стандарт MPI включает интерфейсы pMPI для профилирования вызовов MPI. Этот интерфейс также позволяет легко добавлять контрольные суммы или другую проверку данных ко всем процедурам передачи сообщений.
Для большого объема низко служебный бизнес, передающий Вас, мог бы хотеть проверить OAMQ с несколькими продуктами. Различный OpenAMQ с открытым исходным кодом, предположительно, выполняет торговлю в JP Morgan, таким образом, это должно быть надежно, не так ли?
Сокеты использования MPI внизу, поэтому действительно единственной разницей должен быть API, с которым взаимодействует через интерфейс Ваш код. Вы могли точно настроить протокол, если Вы используете сокеты непосредственно, но это об этом. Что точно Вы делаете с данными?
Сокеты Использования MPI, и если Вы знаете то, что Вы делаете Вас, могут, вероятно, вытащить больше пропускной способности из сокетов, потому что Вы не должны отправлять столько же метаданных.
Но необходимо знать то, что Вы делаете, и это, вероятно, будет более подвержено ошибкам. по существу Вы заменили бы mpi своим собственным протоколом обмена сообщениями.
Я должен буду согласиться с OldMan и свободным пространством. Если Вы не знаете об определенном и улучшении некоторой полезной метрики (производительность, пригодность для обслуживания, и т.д.) по MPI, почему изобретают велосипед. MPI представляет большую сумму общих знаний относительно проблемы, которую Вы пытаетесь решить.
Существует огромное количество проблем, которые необходимо решить, который является вне просто передающих данных. Установление соединения и обслуживание все станут Вашей ответственностью. Если MPI является точной абстракцией (это кажется, что это), Вы нуждаетесь, используете его.
По крайней мере использование MPI и более позднего рефакторинга его с Вашей собственной системой является хорошим подходом, стоящим установку и зависимость MPI.
Мне особенно нравится точка OldMan, которую MPI дает Вам намного больше вне простой связи с сокетом. Вы получаете убивание реализации параллельных и распределенных вычислений с прозрачной абстракцией.
Я не использовал MPI, но я использовал сокеты вполне немного. Существует несколько вещей рассмотреть на высокопроизводительных сокетах. Вы делаете много небольших пакетов или большие пакеты? Если Вы делаете, много небольших пакетов рассматривают выключение алгоритма Nagle для более быстрого ответа:
setsockopt (m_socket, IPPROTO_TCP, TCP_NODELAY...);
Кроме того, использование сигналов может на самом деле быть намного медленнее при попытке передать большой объем данных. Давно я сделал тестовую программу, где читатель будет ожидать сигнала, и читать пакет - это получило бы поединок 100 пакетов/секунда. Затем я просто сделал блокирующиеся чтения и получил 10 000 чтений/секунда.
Точка является взглядом на все эти опции, и на самом деле проверьте их. Различные условия сделают различные методы быстрее/медленнее. Это важно для не, только получают мнения, но и проверять их. Steve Maguire говорит об этом в "Написании Основательного Кода". Он использует много примеров, которые парадоксальны, и тестирует их для обнаружения то, что делает лучший/быстрее код.
Преимущество MPI в том, что вы можете осуществлять коллективную связь. Выполнение трансляций / сокращений в O (log p) / * p - ваше количество процессоров * / вместо O (p) - большое преимущество.