Здравствуйте, thesz, Вы писали:
R>>Плюс возможности перегрузок. Представь эта обработка периодическая. И как правильно сказал Gaperton, обмен сообщениями — асинхронный и толерантный к задержкам. Представь 127 ядер непрерывно генерируют эти сообщения для одного агента, успеет он их разгребать? А когда тестировали на нашем 4-ёх ядерном процессоре вроде всё было хорошо...
T>Настоящие программы содержат натуральные способы управления параллелизмом.
T>Выполнение некоторого этапа зависит от результатов выполнения предыдущего. Если это не так, то это взрывной параллелизм, который возникает, например, при умножении матриц (из O(N^2) данных получается O(N^3) операций).
T>В dynamic data flow сообществе с этим отлично умеют бороться. Штука называется throttling, успешно применялась ещё в CM-5, по-моему.
T>Читайте книги, это прикольно.
А теперь и на throttling.
По названию могу предположить, что это что-то типа того, что определяем агента, который вызывает перегрузку и временно отключаем его, и даёт приоритет перегруженному агенту. Если это так, то это ни фига не решение проблемы. Это не что иное как затычка, которая служит для предотвращения съедания всей памяти и падения системы. Но в то же время она снижает производительность системы. Представь система периодически входит в перегрузку и мы периодически отключаем все процессоры кроме одного, что бы разгрузить агнета.
Здравствуйте, remark, Вы писали:
G>>Ты взялся спорить, и заявил, что у разделяемой памяти есть еще и преимущества. Ты этот тезис и доказывай, что они есть.
R>Это что за бред такой? Я сделал утверждение. Если все согласны, то и никто ничего не доказывает. Если кто-то несогласен, то это значит, что он делает обратный тезис, значит оба вольны доказывать свою точку зрения.
Это не бред, а правило научных дискуссий, в первый раз, кстати, появившееся в римском праве. Бремя доказательства истинности тезиса лежит на стороне, выдвигающей этот тезис. Не наоборот. Если ему не следовать, то один дурак способен наворотить столько, что не разгрести и сотне мудрецов. Докажи, например, что Барака Обама — не инопланетянин, а земля не была сотворена за 7 дней вместе со скелетами динозавров.
Это не я должен доказывать, что ты не прав. Хотя я, кстати, привел тебе контрпример с MPI, реакции на который пока нет. Тишина.
Короче, с людьми не соблюдающих элементарных правил дискуссии я не спорю. Либо придерживайся правил, либо — никаких проблем, завязываем, и изволь спорить с пионерами.
R>У тебя, кстати, какая точка зрения? Будь добр высказать её явно. А то за твоей мастерской игрой слов ничего не понятно, начинает складываться такое ощущение, что твоя цель просто бессмысленно поспорить.
Я тебе, кажется, ясно сказал, нет? Я оппонирую тебе в твоем тезисе, что у разделяемой памяти есть неотъемлемые преимущества, которые обязательно потеряются при использовании модели сообщений. Своих тезисов, помимо того, с которым ты согласен, и с которыми тебе удалось бы поспорить, я в данной дискуссии не выдвигаю. Я очень аккуратен с тезисами, отличаю их от "мнений", и стараюсь не нести херню.
Не удивляйся, в дискуссии вовсе не обязательно у обеих сторон должны быть строго противоположные тезисы. В ней доказательство одного тезиса ни как не связано с тезисом противоположной стороны.
Если тебя все-таки интересует мое "мнение" о проблеме (мнение, как известно, во отличии от тезиса, ни доказать ни опровергнуть невозможно, это считай базарный треп), то я сильно сомневаюсь, что класс задач, на которых разделяемая память даст убедительный отрыв от модели с сообщениями, достаточно широк, чтобы это принимать во внимание. Хотя я допускаю, что вполне возможно найти такие примеры. Ты, впрочем, их пока не нашел.
Здравствуйте, Gaperton, Вы писали:
G>Здравствуйте, remark, Вы писали:
G>>>Ты взялся спорить, и заявил, что у разделяемой памяти есть еще и преимущества. Ты этот тезис и доказывай, что они есть.
R>>Это что за бред такой? Я сделал утверждение. Если все согласны, то и никто ничего не доказывает. Если кто-то несогласен, то это значит, что он делает обратный тезис, значит оба вольны доказывать свою точку зрения.
G>Это не бред, а правило научных дискуссий, в первый раз, кстати, появившееся в римском праве. Бремя доказательства истинности тезиса лежит на стороне, выдвигающей этот тезис. Не наоборот. Если ему не следовать, то один дурак способен наворотить столько, что не разгрести и сотне мудрецов. Докажи, например, что Барака Обама — не инопланетянин, а земля не была сотворена за 7 дней вместе со скелетами динозавров.
Что-то я только не понял, почему точка, что разделяемая память не имеет преимуществ принята за изначальную и не требующую даказательств. Вообще-то это не доказано. Так что давай так, за изначальную точку принимаем, что разделяемая память лучшая по всем параметрам модель. А дальше применяем твои "правила научных дискуссий".
Отмашка. Начинаем. Пожалуйста, мы все слушаем тебя — теперь ты *должен* даказать, что обмен сообщениями имеет хоть какие-то преимущества перед разделяемой память, а потом, что он лучше во всех ситуациях.
А вот это я вообще не понял твоей @#$ни с вырезанием и игнорированием как раз моих аргументов по существу вопроса в таком контексте, что типа я ничего не доказываю, а ты типа ведёшь "научные дискуссии", и ты опять тычешь своим неревантным примером и говоришь, что я ничего на него не отвечаю, хотя я тебе по поводу него уже отвечал. И как тут не переходить на личности?! Озвучивать я не буду, но мне про тебя уже всё понятно...
Аргументы придётся скопировать ещё раз:
Я между прочим, если ты не заметил, или немеренно игнорируешь, как раз доказываю, что разделяемая память имеет приемущества. Краткое содержание предыдущих серий: (1) обмен сообщениями — это как минимум одна модифицирующая операция с разделяемой памятью (добавлние в очередь) + ещё некий оверхед. Это не может быть быстрее чем просто одна модифицирующая операция с разделяемой памятью. По моему опыту — выигрыш как *минимум* 100 тактов, в реальности может быть и 500. Если мы можем обойтись немодифицирующй операцией над разделяемой памятью, то тут обмен сообщениями будет проигрывать на порядки. (2) ФИФО обмен сообщениями склонен остужать данные в кэше. Это системный фактор касающийся производительности, его сложно описать в терминах микробенчмарка. Но именно поэтому те фреймворки могут обойтись ЛИФО обменом реализуют именно его. Большинство же фреймворков НЕ могут обойтись ЛИФО. (3) обмен сообщениями иногда пораждает очень неприятный феномен перегрузок из-за того, что каждый агнет может генерировать неограниченный объём работы для *других* агентов. Врагу не пожелаешь оказаться в такой ситуации, т.к. как исправлять порой просто не понятно. Мне приходилось просто переписывать на разделяемую память. Плюс проявление эффекта зависит от аппаратной платформы.
Ты же ничего не прокомментировал по сути, зато сотряс много воздуха насчёт распределенных кластеров и того, что обмен сообщениями иногда лучше. Все, конечно, рады твоей эрудиции, но она тут не будет объективным аргументом.
G>Это не я должен доказывать, что ты не прав. Хотя я, кстати, привел тебе контрпример с MPI, реакции на который пока нет. Тишина.
Во-первых, я не раз указывал, что твой пример практически не имеет отношения к вопросу. Во-вторых, ну ты рассмешил, ты сам-то смотрел эту статью? Там во множестве случаев OpenMP быстрее причём на обеих машинах. А вот это факт уже имеет отношение к делу и доказывает, что разделяемая память имеет преимущества перед обменом сообщениями.
G>Короче, с людьми не соблюдающих элементарных правил дискуссии я не спорю. Либо придерживайся правил, либо — никаких проблем, завязываем, и изволь спорить с пионерами.
А какое правило-то? Что твоя точка принимается за аксиоматическую, а моя за требующую доказательства? В споре-то 2 точки зрения, нет?
R>>У тебя, кстати, какая точка зрения? Будь добр высказать её явно. А то за твоей мастерской игрой слов ничего не понятно, начинает складываться такое ощущение, что твоя цель просто бессмысленно поспорить.
G>Я тебе, кажется, ясно сказал, нет? Я оппонирую тебе в твоем тезисе, что у разделяемой памяти есть неотъемлемые преимущества, которые обязательно потеряются при использовании модели сообщений. Своих тезисов, помимо того, с которым ты согласен, и с которыми тебе удалось бы поспорить, я в данной дискуссии не выдвигаю. Я очень аккуратен с тезисами, отличаю их от "мнений", и стараюсь не нести херню.
Ну вот реальное доказательство — посмотри статью, которую ты приводил
G>Не удивляйся, в дискуссии вовсе не обязательно у обеих сторон должны быть строго противоположные тезисы. В ней доказательство одного тезиса ни как не связано с тезисом противоположной стороны.
Т.е. ты согласен с моим тезисом? Замечательно, молодец. Прекращаем дискуссию.
G>Если тебя все-таки интересует мое "мнение" о проблеме (мнение, как известно, во отличии от тезиса, ни доказать ни опровергнуть невозможно, это считай базарный треп), то я сильно сомневаюсь, что класс задач, на которых разделяемая память даст убедительный отрыв от модели с сообщениями, достаточно широк, чтобы это принимать во внимание. Хотя я допускаю, что вполне возможно найти такие примеры. Ты, впрочем, их пока не нашел.
Ну свою-то статью посмотри. Класс задач — научные вычисления.
Здравствуйте, Gaperton, Вы писали:
G>Здравствуйте, remark, Вы писали:
R>>ААААААААААА! Вы вместе?
G>Ага. Что, страшно? По-моему, неплохая у нас компания получилась. Синклер, thesz, и я. Мне нравится.
Ну молодцы, радуйтесь дальше, компания пытающаяся доказывать нерелевантными примерами, стирающая в ответе аргументы оппонента, зато придирающаяся к словам, и обвиняющая в отсутствии этих самых стёртых аргументов, приплетающая какие-то римские дискуссии, несущая логическую ахинею...
Против Синклера и thesz то я ничего не имею, но ты, блин, — настоящий тролль.
Здравствуйте, remark, Вы писали:
R>зато придирающаяся к словам, и обвиняющая в отсутствии этих самых стёртых аргументов, приплетающая какие-то римские дискуссии, несущая логическую ахинею...
Спасибо, что ты мне напомнил, где я нахожусь и с кем разговариваю. Здесь, как говорил Синклер, обычаи напоминают скорее наш новый Comedy Club, чем старый римский парламент.
R>Против Синклера и thesz то я ничего не имею, но ты, блин, — настоящий тролль.
Ссылку на "логическую ахинею" у меня покажи, тролль. За базар надо отвечать.
Здравствуйте, remark, Вы писали:
R>Это что за бред такой? Я сделал утверждение. Если все согласны, то и никто ничего не доказывает. Если кто-то несогласен, то это значит, что он делает обратный тезис, значит оба вольны доказывать свою точку зрения.
Афигеть. Ну тогда я делаю тезис — remark пьет по ночам кровь христианских младенцев. Все согласны? Нет? Ну тггда вперед, доказывай
... << RSDN@Home 1.2.0 alpha 4 rev. 1111 on Windows Vista 6.0.6001.65536>>
T>>Там описано программа умножения матриц для машины динамического потока данных, которая ничего, кроме посылки сообщений, делать не умеет. R>ААААААААААА! Вы вместе? Какое это имеет отношение к тому, что разделяемая память имеет (или не имеет) преимущества перед посылкой сообщений на несколько-процессорных и/или многоядерных системах?
Во-первых, приведён пример программы, подтверждающей слова Gaperton.
Во-вторых, приведены соображения по возможностям управления параллелизмом в системах с посылкой сообщений. Хочешь больше — увеличь что-то, не хватает ресурсов — кое-что урежь.
Ну, и приведён пример (пусть и гипотетический) сильно многоядерной масштабируемой системы. Это третье, и последнее.
И совсем-совсем последнее — с тобой общаются совсем не дураки, а люди, которые были причастны к разработке и оценке многоядерных систем на протяжении трёх лет.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Я не ставлю отсылки уведомлений.
R>А теперь и на throttling. R>По названию могу предположить, что это что-то типа того, что определяем агента, который вызывает перегрузку и временно отключаем его, и даёт приоритет перегруженному агенту. Если это так, то это ни фига не решение проблемы. Это не что иное как затычка, которая служит для предотвращения съедания всей памяти и падения системы. Но в то же время она снижает производительность системы. Представь система периодически входит в перегрузку и мы периодически отключаем все процессоры кроме одного, что бы разгрузить агнета.
Нет.
Читайте книги, это прикольно.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Здравствуйте, remark, Вы писали:
G>>Это не бред, а правило научных дискуссий, в первый раз, кстати, появившееся в римском праве. Бремя доказательства истинности тезиса лежит на стороне, выдвигающей этот тезис. Не наоборот. Если ему не следовать, то один дурак способен наворотить столько, что не разгрести и сотне мудрецов. Докажи, например, что Барака Обама — не инопланетянин, а земля не была сотворена за 7 дней вместе со скелетами динозавров.
R>Что-то я только не понял, почему точка, что разделяемая память не имеет преимуществ принята за изначальную и не требующую даказательств. Вообще-то это не доказано.
Ты не понял, так я тебе разъясню. За изначальную точку принято то, что не известно, имеет ли разделяемая память преимущества или нет. Тебе понятна разница меджу "имеет", "не имеет" и "не известно"? Когда ты переходишь от "не известно" к "имеет", или "не имеет" — ты выдвигаешь тезис, он требует доказательства, и это доказательство может быть оспорено.
R>Так что давай так, за изначальную точку принимаем, что разделяемая память лучшая по всем параметрам модель. А дальше применяем твои "правила научных дискуссий".
С какой это стати? За начальную точку принимаем, что неизвестно, какая лучшая и покаким параметрам. Я выдвинул тезис, подразумевающий существование недостатков у разделяемой памяти, и заявил, что этих недостатков нет в модели на сообщениях. Ничего кроме этого я не говорил. По этому тезису — готов его попробовать доказать. Ты можешь по всем понятиям придираться к этому тезису и всем его пунктам.
R>Отмашка. Начинаем. Пожалуйста, мы все слушаем тебя — теперь ты *должен* даказать, что обмен сообщениями имеет хоть какие-то преимущества перед разделяемой память, а потом, что он лучше во всех ситуациях.
Извини, без меня начинай. Я доказываю только те тезисы, которые выдвигаю сам. Ты же сейчас с какого то дуба решил, что тезис "что разделяемая память лучшая по всем параметрам модель" не надо доказывать, и просишь меня его опровергнуть, опять грубо нарушая правила благородной научной дискуссии .
R>А вот это я вообще не понял твоей @#$ни...
Ты попал под пункт правил о матюгах, и тебя за эту строку могут забанить на законном основании.
R> с вырезанием и игнорированием как раз моих аргументов по существу вопроса в таком контексте, что типа я ничего не доказываю, а ты типа ведёшь "научные дискуссии", и ты опять тычешь своим неревантным примером и говоришь, что я ничего на него не отвечаю, хотя я тебе по поводу него уже отвечал. И как тут не переходить на личности?! Озвучивать я не буду, но мне про тебя уже всё понятно...
Просто — взять, и не переходить. Или будешь общаться с кем-то еще. Тролль, блин.
R>Аргументы придётся скопировать ещё раз:
Давай посмотрим на твои аргументы.
R>Я между прочим, если ты не заметил, или немеренно игнорируешь, как раз доказываю, что разделяемая память имеет приемущества. Краткое содержание предыдущих серий: R>(1) обмен сообщениями — это как минимум одна модифицирующая операция с разделяемой памятью (добавлние в очередь) + ещё некий оверхед. Это не может быть быстрее чем просто одна модифицирующая операция с разделяемой памятью. По моему опыту — выигрыш как *минимум* 100 тактов, в реальности может быть и 500. Если мы можем обойтись немодифицирующй операцией над разделяемой памятью, то тут обмен сообщениями будет проигрывать на порядки.
Это доказательство рассчитано на пионеров. В случае модели с сообщениями и разделяемой памяти дизайн программы будет до такой степени разным, что прямого соответствия между очередями и примитивами наблюдаться не будет. Сравнивать надо на реальных задачах. Пример — посмотри, насколько различается производительность теста LINPACK на SMP машине для OpenMP и MPI. Фокус в том, что для случая MPI применяется другой, блочный алгоритм умножения, никто на сообщениях разделяемую память не эмулирует — дураки только в твоем воображении существуют. Это — релевантный пример, и если ты этого понять не в состоянии, то разговаривать больше не о чем.
> (2) ФИФО обмен сообщениями склонен остужать данные в кэше. Это системный фактор касающийся производительности, его сложно описать в терминах микробенчмарка. Но именно поэтому те фреймворки могут обойтись ЛИФО обменом реализуют именно его. Большинство же фреймворков НЕ могут обойтись ЛИФО.
Приведи пример реальной задачи, а не микробенчмарка, где это будет проблемой и просадит мне производительность хотя бы на 2 процента. Это не является проблемой в случае MPI — никто этого эффекта в реальности не наблюдает.
Если бы ты смог привести пример задачи, я бы убрал оттуда микропараллелизм при переходе на модель сообщений, и с высокой вероятностью выиграл по производительности по сравнению с тобой.
> (3) обмен сообщениями иногда пораждает очень неприятный феномен перегрузок из-за того, что каждый агнет может генерировать неограниченный объём работы для *других* агентов. Врагу не пожелаешь оказаться в такой ситуации, т.к. как исправлять порой просто не понятно. Мне приходилось просто переписывать на разделяемую память. Плюс проявление эффекта зависит от аппаратной платформы.
С этим эффектом слишком легко бороться — достаточно притормозить посылателя. Пример системы, где эта проблема решена на уровне шедулера — Erlang. Я уверен, что в MPI она тоже решена.
R>Ты же ничего не прокомментировал по сути, зато сотряс много воздуха насчёт распределенных кластеров и того, что обмен сообщениями иногда лучше. Все, конечно, рады твоей эрудиции, но она тут не будет объективным аргументом.
Я тебе привел ссылку на ИССЛЕДОВАНИЕ ПРОИЗВОДИТЕЛЬНОСТИ, где MPI основанный на сообдщениях в большинстве случаев БЫСТРЕЕ чем система на OpenMP НА ОБЩЕЙ ПАМЯТИ НА ОДНОЙ МАШИНЕ.
Вот это — факт, хочешь ты того или нет. Объясни результат — почему MPI обходит НА ОДНОЙ МАШИНЕ систему с общей памятью OpenMP. Объясни, как так выходит, что практика не пожтверждает твои теоретические выкладки. Тебе еще исследований подкинуть?
G>>Это не я должен доказывать, что ты не прав. Хотя я, кстати, привел тебе контрпример с MPI, реакции на который пока нет. Тишина.
R>Во-первых, я не раз указывал, что твой пример практически не имеет отношения к вопросу.
А я не понял, почему не имеет. Давай, ты претендуешь, что ты умнее меня, знаешь что-то, чего я не знаю? Валяй, я не против, растолкуй мне подробно, что тут не так. Давай по пунктам проверим:
1) MPI — построена на обмене сообщениями? Да.
2) OpenMP — построена на общей памяти? Да.
3) На одной и то же SMP машине, без всяких кластеров, кто быстрее? MPI в подавляющем большинстве случаев, за редкими исключениями.
Что не так?
> Во-вторых, ну ты рассмешил, ты сам-то смотрел эту статью? Там во множестве случаев OpenMP быстрее причём на обеих машинах. А вот это факт уже имеет отношение к делу и доказывает, что разделяемая память имеет преимущества перед обменом сообщениями.
Да чо ты говоришь. Что ж в этой статье Conclusion-то такой странный тогда, а?
We have demonstrated that it is absolutely not obvious
to get better performance with OpenMP codes compared to
MPI ones on shared memory machines. The `naive' loop
level OpenMP version is simply not competitive compared
to MPI and other OpenMP versions. The `improved' loop
level version which uses less parallel regions provides very
limited performance improvement.
...
However, SPMD programming
style is not enough because 1) the code generation of the
compiler for handling thread private arrays may limit signi
cantly the performance and 2) the performance of shared
memory algorithms for interthread communications may be
lower than the one of MPI.
...
И нашел еще две статьи, ты только не волнуйся — с аналогичным результатом, где OpenMP сосет.
G>>Короче, с людьми не соблюдающих элементарных правил дискуссии я не спорю. Либо придерживайся правил, либо — никаких проблем, завязываем, и изволь спорить с пионерами.
R>А какое правило-то? Что твоя точка принимается за аксиоматическую, а моя за требующую доказательства? В споре-то 2 точки зрения, нет?
Выше я тебе достаточно доходчиво объяснил.
R>Т.е. ты согласен с моим тезисом? Замечательно, молодец. Прекращаем дискуссию.
Нет конечно, ты вообще ничего связного сказать не можешь в его защиту. По крайней мере пока у тебя очень слабенько получается. Над доказательствами надо работать, поменьше рвать тельняшку на груди, и побольше думать.
G>>Если тебя все-таки интересует мое "мнение" о проблеме (мнение, как известно, во отличии от тезиса, ни доказать ни опровергнуть невозможно, это считай базарный треп), то я сильно сомневаюсь, что класс задач, на которых разделяемая память даст убедительный отрыв от модели с сообщениями, достаточно широк, чтобы это принимать во внимание. Хотя я допускаю, что вполне возможно найти такие примеры. Ты, впрочем, их пока не нашел.
R>Ну свою-то статью посмотри. Класс задач — научные вычисления.
Да ну? А тут какой-то тролль давеча с матюгами орал, что этот пример не имеет отношения к делу? Кто ж был этот тролль, а, не напомнишь?
Здравствуйте, Gaperton, Вы писали:
G>>>Не стесняйся, опиши реальную серверную задачу, а я тебе ее положу на Эрланг, и она отлично заработает. Думаешь, в первый раз? RRM>>Кстати а почему серверную? Stanalone приложение параллельным быть права не имеет?
G>Блин, да опиши какую хочешь, мне все равно. Но реальную, чтобы можно было выбирать подход к распараллеливанию.
Есть такая забавная пенисометрия -- WideFinder-2. И ее результаты здесь. На первом месте решение на C++, которое работает на основе разделяемой памяти.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, Gaperton, Вы писали:
G>1) MPI — построена на обмене сообщениями? Да. G>2) OpenMP — построена на общей памяти? Да. G>3) На одной и то же SMP машине, без всяких кластеров, кто быстрее? MPI в подавляющем большинстве случаев, за редкими исключениями.
G>Что не так?
For CG class A, SPMD OpenMP provides a signifcant improvement over both MPI and other OpenMP versions (up to 15% over MPI, and 140% over `naive' OpenMP). For CG class B, MPI and SPMD OpenMP provide similar performance. The gain over `naive' OpenMP remains of about 15%.
For MG, the `optimized' and `improved' loop level versions provide good results (more than 30% better than MPI) for class A. For class B the `improved' version is less effcient than the `optimized' one. The SPMD OpenMP code is competitive with the others OpenMP versions for both classes.
For FT, the `optimized' version outperforms the others including MPI. The improvement comes from a performance tuning of the code based on array shape modifcation. SPMD OpenMP provides a
at 15% improvement over MPI for class A and a non-uniform advantage (up to 25%) over MPI for class B. `Naive' and `improved' versions show a decreasing effciency for class A and reach MPI performance for class B.
For LU, SPMD OpenMP provides only a little advantage (about 15%) over MPI for class B. The other OpenMP implementations show a high negative slope meaning that they do not scale.
Еще там нет таких четких указаний на то, что SPMD OpenMP версия дает лучшую производительность в тесте CG (классы A и B), но по приведенным на рисунке 8 графике видно, что это преимущество на IBM NH2 таки есть.
И это при том, что SPMD OpenMP версия была реализована как адаптированный к OpenMP вариант MPI решения. Так что не факт, что реализованная с изначальным прицелом на OpenMP программа не показала бы еще более высокой скорости работы.
G>Да чо ты говоришь. Что ж в этой статье Conclusion-то такой странный тогда, а?
G>
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. The `naive' loop
G>level OpenMP version is simply not competitive compared
G>to MPI and other OpenMP versions. The `improved' loop
G>level version which uses less parallel regions provides very
G>limited performance improvement.
G>...
G>However, SPMD programming
G>style is not enough because 1) the code generation of the
G>compiler for handling thread private arrays may limit signi
G> cantly the performance and 2) the performance of shared
G>memory algorithms for interthread communications may be
G>lower than the one of MPI.
G>...
И еще там же:
The performance analysis (hardware performance
counters and breakdown of the execution time) of our OpenMP
SPMD version of the NAS benchmark demonstrates that we
succeed in getting the same performance as the MPI version
for the computing loops and better performance than the
MPI version for the communication part.
Сюда же нужно добавить интересные оговорки из текста статьи:
While nested parallelism with standard directives may generate effcient code for non-dynamic loop boundaries (typically: dense linear algebra), tests on a Compaq-HP ES40 4-way SMP machine demonstrate for the conjuguate gradient case (featuring dynamic boundaries computations) performance lesser than the one obtained with the sequential code. The analyze of the generated assembly code shows that the compiler produces a much larger executable code than for the singlelevel parallelism, including heavy management cost due to dynamic loop boundaries computation.
и
For our experiments, we have chosen three kernels (CG, MG, FT), and a mini application (LU) among the NAS (NPB) benchmark suite developed at NASA Ames Research Center [13]. We selected them because 1) they are well recognized by the parallel programming community, 2) the MPI version is highly tuned and 3) they feature dierent communication patterns and computation/communication ratio during their executions.
Т.е. круто оптимизированные MPI версии сравниваются с OpenMP компиляторами, которые временами генерят очень корявый код.
Ну и так, к слову:
The IBM SP3 Night Hawk II node features sixteen Power3+ processors at 375 MHz. They are connected to the main memory (up to 16 GB) by a crossbar switch, with a bandwidth up to 14.2 GB/s. The cache for each processor is 16KB of L1 and 8MB for the L2. The programs are compiled with XLF 7.1 using the options: -O3 -bmaxdata:0x80000000 -qcache=auto -qarch=auto -qtune=auto -qmaxmem=-1 -qunroll -qnosave.
The programs are executed via the LoadLeveler proprietary queuing system. We use the shared memory version of the MPI library in order to get the best performance.
У разделяемой памяти настолько нет никаких преимуществ, что иследователи из упомянутой статьи используют реализванную на основе разделяемой памяти MPI библиотеку специально для получения наилучшей производительности.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
E>Есть такая забавная пенисометрия -- WideFinder-2. И ее результаты здесь. На первом месте решение на C++, которое работает на основе разделяемой памяти.
А на каком месте решение на основе передачи сообщений?
Здравствуйте, Константин Б., Вы писали:
E>>Есть такая забавная пенисометрия -- WideFinder-2. И ее результаты здесь. На первом месте решение на C++, которое работает на основе разделяемой памяти.
КБ>А на каком месте решение на основе передачи сообщений?
Среди результатов WideFinder-2 я вообще не видел Erlang-а. Был там какой-то вариант на Scala, может быть со ScalaActors.
Решения на Erlang-е были в WideFinder-1: http://www.tbray.org/ongoing/When/200x/2007/10/30/WF-Results
Лучший вариант на Erlang в два раза медленее победителя на Perl-е. Но первый WideFinder был не очень показательным, так что вряд ли имеет смысл на него смотреть.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, Gaperton, Вы писали:
G>Я тебе привел ссылку на ИССЛЕДОВАНИЕ ПРОИЗВОДИТЕЛЬНОСТИ, где MPI основанный на сообдщениях в большинстве случаев БЫСТРЕЕ чем система на OpenMP НА ОБЩЕЙ ПАМЯТИ НА ОДНОЙ МАШИНЕ.
Просто-напросто, модель OpenMP не подходит для многих задач.
Что тут такого удивительного, не понимаю?
OpenMP задумывался для реализации неинтрузивного параллелизма в С-шных программах. Естественно, его примитивы поэтому оказались не самыми оптимальными для многих условий. Зато на нём писать легко.
Если делать задачи на разделяемой памяти с нормальными явными блокировками и потоками, то тут будет совсем другая картина.
Здравствуйте, eao197, Вы писали:
G>>>>Не стесняйся, опиши реальную серверную задачу, а я тебе ее положу на Эрланг, и она отлично заработает. Думаешь, в первый раз? RRM>>>Кстати а почему серверную? Stanalone приложение параллельным быть права не имеет?
G>>Блин, да опиши какую хочешь, мне все равно. Но реальную, чтобы можно было выбирать подход к распараллеливанию.
E>Есть такая забавная пенисометрия -- WideFinder-2. И ее результаты здесь. На первом месте решение на C++, которое работает на основе разделяемой памяти.
Я нихрена не понимаю Руби, и разбираться с ним ради теста — лень. Если ты дашб нормальное объяснение — могу прогу сделать. Правда, в Эрланге медленный ввод вывод, и поэтому он обычно проигрывает в этих тестах Питону. Но это мы еще посмотрим — думаю, шансы порвать Питон у меня есть.
Насколько я понял, это задача на анализ файла. Параллелится на основе сообщений тривиально на любом языке — применяя поток данных и "ленивые вычисления". Вот решение в лоб:
1. один поток читает файл, выполняя минимальный лексический разбор — вычленяя записи друг от друга, откладывая всю возможную работу на потом, и раздает их как сообщения воркерам.
2. воркеры завершают парсинг, вычисляя статистику.
3. воркеры посылают результат в тот процесс, который хранит каждую статистику. Ну, типа топ 10 там отбирает, и все .
И все. Простая труба. Не вижу никаких сложностей. И не важно, на Erlang это будет, или на С++, С# или F#. Для С++ потребуется толковый класс треда, очереди сообщений, и хороший аллокатор.
Кстати, я подозреваю, что С# и F# войдут в топ на этом тесте, если применять обмен сообщениями — они быстры, и у них хороший аллокатор и сборщик мусора, так что там будет легко избежать копирования сообщений при передаче, и не будет лишних расходов на подсчет ссылок.
Здравствуйте, Cyberax, Вы писали:
G>>Я тебе привел ссылку на ИССЛЕДОВАНИЕ ПРОИЗВОДИТЕЛЬНОСТИ, где MPI основанный на сообдщениях в большинстве случаев БЫСТРЕЕ чем система на OpenMP НА ОБЩЕЙ ПАМЯТИ НА ОДНОЙ МАШИНЕ. C>Просто-напросто, модель OpenMP не подходит для многих задач.
C>Что тут такого удивительного, не понимаю?
А я разве удивляюсь? Это вон remark так удивился, что аш в истерике зашелся .
Тише, не спугни его, я хочу посмотреть, у него ума хватит в интернете что-нибудь поискать, или нет.
C>Если делать задачи на разделяемой памяти с нормальными явными блокировками и потоками, то тут будет совсем другая картина.
Ну да, а на ассемблере можно MS SQL Server написать, а чайной ложкой вырыть тоннель под ЛаМаншем .
Здравствуйте, Gaperton, Вы писали:
G>Я нихрена не понимаю Руби, и разбираться с ним ради теста — лень.
Изначально все пошло из этого:
In my Finding Things chapter of Beautiful Code, the first complete program is a little Ruby script that reads the ongoing Apache logfile and figures out which articles have been fetched the most. It’s a classic example of the culture, born in Awk, perfected in Perl, of getting useful work done by combining regular expressions and hash tables. I want to figure out how to write an equivalent program that runs fast on modern CPUs with low clock rates but many cores; this is the Wide Finder project.
В WideFinder-2 добавились следующие требования:
Based on discussion on this page, I have proposed, and have heard no real objections, that we adopt a suggestion originally entitled "normal HTML report", as follows:
Report the top 10 URIs, by hits, which are articles (much the same regex as before)
Report the top 10 URIs of any kind by aggregate byte count downloaded
Report the top 10 URIs of any kind that returned 404 Not Found
Report the top 10 client addresses that fetched hit-counted articles
Report the top 10 referrers for hit-counted articles
G>Но это мы еще посмотрим — думаю, шансы порвать Питон у меня есть.
Питон там давно порвали на британский флаг.
G>1. один поток читает файл, выполняя минимальный лексический разбор — вычленяя записи друг от друга, откладывая всю возможную работу на потом, и раздает их как сообщения воркерам.
Ага, вычитывает блоки по несколько Mb, а затем высылает их другим процессам/нитям.
А если не высылает, а передает указатель на преаллоцированный буфер, то что это такое, как не использование разделяемой памяти?
G>Для С++ потребуется толковый класс треда, очереди сообщений, и хороший аллокатор.
Победитель просто использует boost::thread без очередей сообщений и аллокатора.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, thesz, Вы писали:
C>>Проблема с message passing в том, что работать с большими массивами меняющихся данных так может быть очень неудобно. T>Это как это так это вот?
Это когда несколько потоков одновременно работают с одними разделяемыми данными и совместно их меняют.
T>Неудобно с какой точки зрения?
Нужно, фактически, создавать абстракцию разделяемой памяти с помощью сообщений.
T>Если что, то анализ потока данных с учётом пространства выполнения программы может помочь в автоматическом преобразовании императивных программ в программы с посылкой сообщений.
Это далеко не всегда возможно, да и вообще — это тупой подход.
Императивные программы просто надо специально под многопоточность рассчитывать.
Задачу разбирать будем, или как? 
Кто ж был этот тролль, а, не напомнишь?
