Здравствуйте, Gaperton, Вы писали:
R>>Дабы не быть голословным — вот пример, где разделяемая память на 2-3 порядка (100-1000 раз) быстрее, чем обмен сообщениями на современном многоядерном железе: R>>http://www.rsdn.ru/forum/message/3187084.1.aspx
G>Ага. Быстрее. До той поры, пока ты не догадаешься в данном примере применить для обмена сообщениями lock-free очередь. Тогда, волшебным образом, обмен сообщениями станет быстрее разделяемой памяти .
Вообще, обычно, у меня хорошо с отличением и понимаем шуток... Но ты ставишь меня просто в тупик...
Хммм... Ну на самом деле если я посмеюсь: ХА-ХА-ХА-ХА-ХА [небольшой отдых] ХА-ХА-ХА-ХА-ХА
то это будет релевантно под оба варианта: если это шутка и нет.
Если это не шутка, то это будет релевантно, т.к. lock-free очередь не будет быстрее даже спин-лока. Т.е. все оверхеды на обмен сообщениями так и останутся выше, чем у разделяемой памяти (там где они были выше).
А уж по поводу ситуации, где нам надо только считать данные — обмен сообщениями (на любых очередях), так и останется медленнее на несколько порядков.
Lock-free НЕ имеет никакого отношения ни к производительности, ни к масштабируемости, Lock-free — это ТОЛЬКО о гарантиях системного прогресса: http://rsdn.ru/Forum/message/2930849.1.aspx
Кстати, какой именно алгоритм lock-free очереди ты имеешь в виду?
G>Хреновый у тебя пример, на самом деле.
Хреновый для чего? Хреновый для выставления достоинств передачи сообщений? Согласен. Но ведь мы сейчас выставляем достоинства разделяемой памяти. Иногда ведь, знаешь, надо и глобальное время (или что-то типа этого) откуда-то считать; а откуда его считать, если мы от разделяемой памяти отказались в принципе? Придётся сообщения слать агенту, который за время отвечает... ну либо на каждый тик делать широковещательную рассылку... А так могли бы просто считать слово из памяти...
C>Проблема с message passing в том, что работать с большими массивами меняющихся данных так может быть очень неудобно.
Это как это так это вот?
Неудобно с какой точки зрения?
Если что, то анализ потока данных с учётом пространства выполнения программы может помочь в автоматическом преобразовании императивных программ в программы с посылкой сообщений.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Здравствуйте, remark, Вы писали:
R>Если у нас будет паттерн запрос-ответ (клиент-сервер), то всё будет намного хуже — будет ещё блокирование клиента, отправка ответа, доставание ответа, разблокирование клиента.
Все, хватит нести чушь и полоскать людям мозг. Надоело. Вот есть факт. Программы на MPI, основанные на передаче сообщений, в большинстве случаев быстрее, чем программы под OpenMP, который построен на разделяемой памяти. Даже на одной машине. Это наблюдаемый факт. А твои слова — это бла-бла-бла. Вот обгони для начала на разделяемой памяти умножение MPI-ное матриц на многоядерном проце, как ты говоришь, "на два порядка", и тогда будешь говорить мне, что там сказать честнее. Умнные все стали, сил нет, языками чесать.
http://www.lri.fr/~gk/QUID/papers/SPAA2003.pdf
We have demonstrated that it is absolutely not obvious
to get better performance with OpenMP codes compared to
MPI ones on shared memory machines.
А на нескольких машинах, к сведению, OpenMP не просто отстает, он С.О.С.Е.Т. Именно так. Причина в том, что модель на сообщениях — асинхронна, и поэтому хорошо толерантна к высоким задержкам. Почему и дает почти линейную масштабируемость.
S>>Вот хочется точно понять, почему такие же трюки неприменимы к передаче сообщений.
R>Модель не предусматривает таких оптимизаций. Мы же сознательно открещиваемся от разделяемых данных. А это как раз оптимизации, которые хорошо ложатся именно на разделяемые данные, потому что данные... *разделяемые* по сути своей.
Модель вообще не касается оптимизаций — модель есть модель. Она допускает любые оптимизации, не нарушающие семантику.
Религиозные соображения в духе "мы же сознательно открещиваемся" — нам, инженерам, малоинтересны. Вы открещиваетесь? Открещивайтесь дальше.
Какое отношение имеют твои фантазии к реальности, я показал на примере MPI и OpenMP.
Здравствуйте, remark, Вы писали:
R>>>>>Я надеюсь, это шутка?
G>>>>Ты о чем? О том, что у современных суперкомпьютеров нет общей памяти? Нет, это не шутка. Разделяемой памяти у них нет, правда.
R>>>Нет, я не об этом. Я о том, что ты серьёзно утверждаешь, что у разделяемой памяти нет приемуществ.
G>>Да ну? Правда штоли? А можно мне посмотреть на мой пост, где я это говорю?
R>Ну тогда — извини. Я просто не понял (и не понимаю) твоё высказывание, что будет НЕ честнее сказать, что у модели актёров нет преимуществ и недостатков разделяемой памяти (вместо только недостатков).
Убить нельзя помиловать. Твою фразу вполне корректно с точки зрения русского языка трактовать так, как будто у сообщений нет преимуществ [перед разделяемой памятью] в принципе.
Даже если твою фразу понимать так, как ты здесь пишешь, то тезис о наличии значимых преимуществ у разделяемой памяти, которых якобы лишена модель передачи сообщений, тебе надо для начала доказать. Потому, например, что практика применения MPI и OpenMP его на данный момент не подтверждает. MPI во многих случаях быстрее, чем OpenMP даже на SMP конфигурациях с общей памятью.
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, remark, Вы писали: S>Итак, у нас есть некоторое число s. Поток 1 передает его в поток 2; поток 2 прибавляет к s некое число q, известное только ему, и возвращает обратно.
Это немного нечестно предлагать пример оптимизированный под модель обмена соообщениями.
Вот другой пример:
Есть некое число s инициализированное нулем.
Несколько потоков каждый из которых читает это число и увеличивает на известное только ему значение. Далее поток как-то обрабатывает прочитанное значение.
Можно взглянуть на решение этой задачи с помощью посылки сообщений?
Здравствуйте, Gaperton, Вы писали:
G>>>Да ну? Правда штоли? А можно мне посмотреть на мой пост, где я это говорю?
R>>Ну тогда — извини. Я просто не понял (и не понимаю) твоё высказывание, что будет НЕ честнее сказать, что у модели актёров нет преимуществ и недостатков разделяемой памяти (вместо только недостатков).
G>Убить нельзя помиловать. Твою фразу вполне корректно с точки зрения русского языка трактовать так, как будто у сообщений нет преимуществ [перед разделяемой памятью] в принципе.
Хммм... мне кажется, что, что бы трактовать так как ты подумал, там должна была бы быть запятая: ...проблем, и преимуществ...
G>Даже если твою фразу понимать так, как ты здесь пишешь, то тезис о наличии значимых преимуществ у разделяемой памяти, которых якобы лишена модель передачи сообщений, тебе надо для начала доказать. Потому, например, что практика применения MPI и OpenMP его на данный момент не подтверждает. MPI во многих случаях быстрее, чем OpenMP даже на SMP конфигурациях с общей памятью.
Здравствуйте, Sinclair, Вы писали:
R>>Это будет дешевле и значительно быстрее чем обмен сообщениями — нет никаких очередей, блокирований/разблокирований потоков, S>А как же lock()? Ты думаешь, lock() не приведет к блокировке потока в ожидании того, пока кто-то другой не сделает unlock()?
Грамотная реализация мьютекса под SMP даже в случае если невозможности захвата мьютекса не будет сразу блокировать поток, а некоторое время покрутиться на спин локе в юзер моде ожидая быстрого освобождения мьютекса и только если мьютекс не освободится заблокирует поток в ядре. В случае очень коротких блокировок мьютексы могут работать без переходя в ядро для блокировки потока, даже если есть реальная конкуренция между потоками
Здравствуйте, remark, Вы писали:
R>Здравствуйте, Gaperton, Вы писали:
G>>>>Да ну? Правда штоли? А можно мне посмотреть на мой пост, где я это говорю?
R>>>Ну тогда — извини. Я просто не понял (и не понимаю) твоё высказывание, что будет НЕ честнее сказать, что у модели актёров нет преимуществ и недостатков разделяемой памяти (вместо только недостатков).
G>>Убить нельзя помиловать. Твою фразу вполне корректно с точки зрения русского языка трактовать так, как будто у сообщений нет преимуществ [перед разделяемой памятью] в принципе.
R>Хммм... мне кажется, что, что бы трактовать так как ты подумал, там должна была бы быть запятая: ...проблем, и преимуществ...
Форумный язык таков, что запятую можно и пропустить, это нормально и на это никто не обращает внимания. К тому же, слово "преимуществ" ты выделил болдом, что играет роль запятой, отделяя его от предыдущих слов акцентом. Можно, можно было так воспринять. Я так и воспринял.
Здравствуйте, Gaperton, Вы писали:
R>>Если у нас будет паттерн запрос-ответ (клиент-сервер), то всё будет намного хуже — будет ещё блокирование клиента, отправка ответа, доставание ответа, разблокирование клиента.
G>Все, хватит нести чушь и полоскать людям мозг. Надоело. Вот есть факт. Программы на MPI, основанные на передаче сообщений, в большинстве случаев быстрее, чем программы под OpenMP, который построен на разделяемой памяти. Даже на одной машине. Это наблюдаемый факт. А твои слова — это бла-бла-бла. Вот обгони для начала на разделяемой памяти умножение MPI-ное матриц на многоядерном проце, как ты говоришь, "на два порядка", и тогда будешь говорить мне, что там сказать честнее. Умнные все стали, сил нет, языками чесать.
G>http://www.lri.fr/~gk/QUID/papers/SPAA2003.pdf G>We have demonstrated that it is absolutely not obvious G>to get better performance with OpenMP codes compared to G>MPI ones on shared memory machines.
G>А на нескольких машинах, к сведению, OpenMP не просто отстает, он С.О.С.Е.Т. Именно так. Причина в том, что модель на сообщениях — асинхронна, и поэтому хорошо толерантна к высоким задержкам. Почему и дает почти линейную масштабируемость.
Это уже становится интереснее — хотя бы какие-то объяснения с твоей стороны. Обязательно прочитаю статью.
НО, во-первых, что бы показать, что у разделяемой памяти нет преимуществ, ты должен приводить ситуации благоприятные для разделяемой памяти, если окажется, что таких ситуаций не удаётся найти или по всех них разделяемая память проигрывает, тогда возможно у неё действительно нет преимуществ.
Приводить же просто какие-то ситуации и показывать на них, что обмен сообщениями оказывается быстрее — бессмысленно. Это никак не показывает, что у разделяемой памяти нет преимуществ.
Во-вторых, что бросается в глаза, они тестируют на неких IBM SP3 Night Hawk II и SGI Origin 3800 — если не ошибаюсь, то это всё датировано 2000 годом и ранее. Это машины прошлого поколения, во-вторых, очень специфические. Я ориентируюсь и говорю про машины, которые использует 99% из нас сейчас — либо однопроцессорные многоядерные, либо несколько-процессорные многоядерные. Опять же, если на тех машинах обмен сообщениями оказывается быстрее, то это никак не говорит в пользу того, что у разделяемой памяти не преимуществ вообще (ну точнее говорит, но очень-очень слабо).
Когда прочитаю статью прокомментирую по-сути статьи.
Да, на экзотических распределенных машинах для супер-вычислений разделяемая память С.О.С.Е.Т. С этим никто не спорит. Там просто нет разделяемой памяти. Но это, в принципе, и мало кому интересно. Сколько процентов из нас разрабатывает ПО для распределенных кластеров?
Для того, что бы показать, что у разделяемой памяти ЕСТЬ преимущества мне НЕ надо обгонять MPI умножение матриц. И уж точно не надо это делать ВНАЧАЛЕ.
Я надеюсь, что это ты просто специально пытаешь внести некоторые логические ошибки в свои доказательства, что бы доказать свою точку зрения.
Здравствуйте, Gaperton, Вы писали:
R>>Если у нас будет паттерн запрос-ответ (клиент-сервер), то всё будет намного хуже — будет ещё блокирование клиента, отправка ответа, доставание ответа, разблокирование клиента.
G>Все, хватит нести чушь и полоскать людям мозг. Надоело. Вот есть факт. Программы на MPI, основанные на передаче сообщений, в большинстве случаев быстрее, чем программы под OpenMP, который построен на разделяемой памяти. Даже на одной машине. Это наблюдаемый факт. А твои слова — это бла-бла-бла. Вот обгони для начала на разделяемой памяти умножение MPI-ное матриц на многоядерном проце, как ты говоришь, "на два порядка", и тогда будешь говорить мне, что там сказать честнее. Умнные все стали, сил нет, языками чесать.
Gaperton, ты как-то изличше категоричен. OpenMP — это вообще частный случай разделяемой памяти, не всегда удачный или применымий. Он вообще заточен под вычислительные задачи. Я думаю никому не прийдет в голову пытаться делать например разделяемый кэш на OpenMP. Так что не надо эти результаты экстраполировать на все возможные варианты разделяемой памяти.
G>http://www.lri.fr/~gk/QUID/papers/SPAA2003.pdf G>We have demonstrated that it is absolutely not obvious G>to get better performance with OpenMP codes compared to G>MPI ones on shared memory machines.
G>А на нескольких машинах, к сведению, OpenMP не просто отстает, он С.О.С.Е.Т. Именно так. Причина в том, что модель на сообщениях — асинхронна, и поэтому хорошо толерантна к высоким задержкам. Почему и дает почти линейную масштабируемость.
Возможно сосет в умножении матриц, не более, не надо на все обобщять
S>>>Вот хочется точно понять, почему такие же трюки неприменимы к передаче сообщений.
R>>Модель не предусматривает таких оптимизаций. Мы же сознательно открещиваемся от разделяемых данных. А это как раз оптимизации, которые хорошо ложатся именно на разделяемые данные, потому что данные... *разделяемые* по сути своей.
G>Модель вообще не касается оптимизаций — модель есть модель. Она допускает любые оптимизации, не нарушающие семантику.
G>Религиозные соображения в духе "мы же сознательно открещиваемся" — нам, инженерам, малоинтересны. Вы открещиваетесь? Открещивайтесь дальше.
Ну в таком случае ты согласишься, что MPI реализация в рамках одной машины вполне может опираться на разделяемую память? В любом случае какая-то разделяемая память будет, иначе через что ты передашь сообщени от одного потока к другому?
У всего должно быть свое место, remark сказал, что у разделяемой памяти есть преимущества ктр нет у передачи сообщений . Не дстатки тоже есть, он и не отрицает.
Ты же пытаешься показать, что передача сообщений — некая серебряная пуля и разделяемая память может быть _везде_ заменена на передачу сообщений.
Здравствуйте, RailRoadMan, Вы писали:
S>>Здравствуйте, remark, Вы писали: S>>Итак, у нас есть некоторое число s. Поток 1 передает его в поток 2; поток 2 прибавляет к s некое число q, известное только ему, и возвращает обратно.
RRM>Это немного нечестно предлагать пример оптимизированный под модель обмена соообщениями.
Согласен. Что бы показать, что у разделяемой памяти нет преимуществ, и обмен сообщениями всегда лучше, надо приводить ситуации, которые благоприятны для разделяемой памяти. Только анализ таких ситуаций может показать что-то по существу.
А то вот Gaperton приводит какие-то распределенные кластеры для супер-вычислений, и считает, что он этим что-то доказывает.
Здравствуйте, RailRoadMan, Вы писали:
RRM>Здравствуйте, Sinclair, Вы писали:
S>>Здравствуйте, remark, Вы писали: S>>Итак, у нас есть некоторое число s. Поток 1 передает его в поток 2; поток 2 прибавляет к s некое число q, известное только ему, и возвращает обратно.
RRM>Это немного нечестно предлагать пример оптимизированный под модель обмена соообщениями.
RRM>Вот другой пример: RRM>Есть некое число s инициализированное нулем. RRM>Несколько потоков каждый из которых читает это число и увеличивает на известное только ему значение. Далее поток как-то обрабатывает прочитанное значение.
RRM>Можно взглянуть на решение этой задачи с помощью посылки сообщений?
Пример очень плохой, это совершенно бессмысленный микротест. Потому, что в данном случае очевидно надо воспользоваться коммутативностью и ассоциативностью сложения, и попросить потоки просто прислать свои числа. Если же число зависит от счетчика, то пример некорректен, так как у программы недетерминированное поведение.
Однако, если ты так хочешь — то пожалуйста. Надо заметить, что операции над числом у тебя сериализованы, то есть потоки выполняют операцию по очереди. После чего, главный поток ждет на барьере. Вот, что у тебя происходит.
Оптимизированный вариант на сообщениях — процессы worker-ы объединены в линейный список по PID-ам. Последний worker знает PID главного процесса, главный — PID первого. И действие выполняется передачей сообщения по этому кольцу.
Здравствуйте, RailRoadMan, Вы писали: RRM>Грамотная реализация мьютекса под SMP даже в случае если невозможности захвата мьютекса не будет сразу блокировать поток, а некоторое время покрутиться на спин локе в юзер моде ожидая быстрого освобождения мьютекса и только если мьютекс не освободится заблокирует поток в ядре. В случае очень коротких блокировок мьютексы могут работать без переходя в ядро для блокировки потока, даже если есть реальная конкуренция между потоками
Грамотная реализация очереди будет делать то же самое.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, RailRoadMan, Вы писали: RRM>Можно взглянуть на решение этой задачи с помощью посылки сообщений?
То же самое. Один поток владеет этим числом; он раскидывает его остальным потокам, они обрабатывают число, а ему кидают сообщение "прибавь дельту".
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, RailRoadMan, Вы писали:
RRM>Это немного нечестно предлагать пример оптимизированный под модель обмена соообщениями.
RRM>Вот другой пример: RRM>Есть некое число s инициализированное нулем. RRM>Несколько потоков каждый из которых читает это число и увеличивает на известное только ему значение. Далее поток как-то обрабатывает прочитанное значение.
RRM>Можно взглянуть на решение этой задачи с помощью посылки сообщений?
Кстати, это как, ничего, что твой пример, который "оптимизирован под разделяемую память" — последовательный, и содержит ноль параллелизма?
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, RailRoadMan, Вы писали: RRM>>Грамотная реализация мьютекса под SMP даже в случае если невозможности захвата мьютекса не будет сразу блокировать поток, а некоторое время покрутиться на спин локе в юзер моде ожидая быстрого освобождения мьютекса и только если мьютекс не освободится заблокирует поток в ядре. В случае очень коротких блокировок мьютексы могут работать без переходя в ядро для блокировки потока, даже если есть реальная конкуренция между потоками S>Грамотная реализация очереди будет делать то же самое.
Опа! Т.е. у нас где-то в очереди будет разделяемый спинлок? Или я не понял мысль?
Здравствуйте, Gaperton, Вы писали:
G>Здравствуйте, RailRoadMan, Вы писали:
RRM>>Это немного нечестно предлагать пример оптимизированный под модель обмена соообщениями.
RRM>>Вот другой пример: RRM>>Есть некое число s инициализированное нулем. RRM>>Несколько потоков каждый из которых читает это число и увеличивает на известное только ему значение. Далее поток как-то обрабатывает прочитанное значение.
RRM>>Можно взглянуть на решение этой задачи с помощью посылки сообщений?
G>Кстати, это как, ничего, что твой пример, который "оптимизирован под разделяемую память" — последовательный, и содержит ноль параллелизма?
А почему бы и нет? Потоки делают ещё и что-то другое, что содержит параллелизм, но так же им надо сделать и это.
Здравствуйте, Gaperton, Вы писали:
G>Кстати, это как, ничего, что твой пример, который "оптимизирован под разделяемую память" — последовательный, и содержит ноль параллелизма?
А ничего, что в примере до этого (ктр про s и q) не сильно больше?
Здравствуйте, RailRoadMan, Вы писали:
G>>Религиозные соображения в духе "мы же сознательно открещиваемся" — нам, инженерам, малоинтересны. Вы открещиваетесь? Открещивайтесь дальше.
RRM>Ну в таком случае ты согласишься, что MPI реализация в рамках одной машины вполне может опираться на разделяемую память? В любом случае какая-то разделяемая память будет, иначе через что ты передашь сообщени от одного потока к другому?
Вы как дети прям малые. Аппаратно передача сообщений в современных процах НЕ ПОДДЕРЖИВАЕТСЯ. Естественно, она будет реализована посредством разделяемой памяти, ПО ДРУГОМУ на современных процах просто НЕЛЬЗЯ, и я не понимаю, как это в принципе может являться предметом спора. Совсем за идиота собеседника держать не надо, ладно?
Тем более, что это совершенно не имеет значения в конткесте разговора, как именно устроена реализация MPI. Главное, что она почему-то часто оказывается на практике на реальных задачах быстрее, чем манипуляции с разделяемой памятью — даже на SMP. Вот незадача.
RRM>Ты же пытаешься показать, что передача сообщений — некая серебряная пуля и разделяемая память может быть _везде_ заменена на передачу сообщений.
Да ну, правда штоли? Ссылку на мое сообщение можно посмотреть? Давай так — ты ссылку сначала найдешь, а потом расскажешь мне про список глупостей, которые я по твоему пытаюсь показать.
.
