Здравствуйте, Gaperton, Вы писали:
G>Для того, чтобы понять, может эта статья может быть контрпримером, или нет, достаточно внимательно прочитать одну ее часть — Conclusion, выдержки из которого я приводил.
Т.е. ты статью не читал, но в качестве примера привел.
G>Если бы ты это сделал, то увидел бы вывод авторов статьи в его начале, что их исследование показало, что далеко не очевидно, что OpenMP дает лучшую производительность на SMP машинах, что является прямым опровержением тезиса.
Конечно не очевидно. Плохая программа на OpenMP сольет крутооптимизированной на MPI (а именно такая рассматривается в статье). Это и ежу понятно, даже классическое образование не нужно. Зато оптимизированная программа на OpenMP обгоняет такую же на MPI. О чем свидетельствуют как графики в самой статье, так и последний абзац того же Conclusion (да, даже Conclusion стоило прочитать полностью).
Кстати, в статье рассматриваются три версии программ на OpenMP. Две из них показывают не очень хорошие результаты. Что и позволяет авторам говорить о неочевидности того, что OpenMP является залогом успеха. Зато третья версия уделывает MPI. Что не позволяет использовать данную статью в качестве опровержения тезисов remark-а.
Более того, как раз третья, самая быстрая, программа, именуемая OpenMP SPMD, является прямым отображением MPI-ной версии на OpenMP. Т.е. люди взяли те же принципы, те же алгоритмы, но заменили обмен сообщениями на работу с общей памятью. И что получили -- сумарное повышение производительности (такую же производительность на вычислениях и большую пропускную способность на коммуникациях). Что и согласуется как раз с предположениями remark-а о более низких накладных расходах при общей памяти.
G>Это не опровержение тезиса?
Неа. Утвеждение may be ни в коей мере не может быть опровержением, ни утверждением.
G>И последнее — тебе правда так сильно докопаться хочется, да?
Когда ты громогласно утверждаешь, что по заключении данной статьи выходит, что OpenMP сосет, а оказывается, что все совсем не так...
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Понятно, то есть, тебе хочется докопаться.
G>>Если бы ты это сделал, то увидел бы вывод авторов статьи в его начале, что их исследование показало, что далеко не очевидно, что OpenMP дает лучшую производительность на SMP машинах, что является прямым опровержением тезиса.
E>Кстати, в статье рассматриваются три версии программ на OpenMP. Две из них показывают не очень хорошие результаты. Что и позволяет авторам говорить о неочевидности того, что OpenMP является залогом успеха. Зато третья версия уделывает MPI. Что не позволяет использовать данную статью в качестве опровержения тезисов remark-а.
Для опровержения тезисов ремарка вполне достаточно одного примера, где "сообщения" показывают лучший результат, а тут их два.
G>>Это не опровержение тезиса?
E>Неа. Утвеждение may be ни в коей мере не может быть опровержением, ни утверждением.
Утверждения may be вполне достаточно для опровержения утверждения, в математике это называется умным словом "контрпример". Что известно всем студентам первого курса, которые не прошляпили высшую математику.
Еще раз, приведу два тезиса:
remark: "разделяемая память" имеет преимущества, которые безвозвратно и необходимо утрачиваются при применении message passing style.
авторы статьи: We have demonstrated that it is absolutely not obvious
to get better performance with OpenMP codes compared to
MPI ones on shared memory machines.
Противоречие налицо. Всего доброго, докапывайся дальше.
Здравствуйте, eao197, Вы писали:
G>>И последнее — тебе правда так сильно докопаться хочется, да?
E>Когда ты громогласно утверждаешь, что по заключении данной статьи выходит, что OpenMP сосет, а оказывается, что все совсем не так...
Вот на это в статье глянь.
Table One: Results for the OpenMP/MPI benchmarks. (winning test is in bold)
И давай я посмотрю, что ты сейчас будешь говорить. Давай, начинай сеанс особой, форумной магии — делай из этой статьи вывод, что OpenMP показывает убедительный отрыв. Ну, например, скажи на всякий случай, что Гапертон статью опять не читал — это никогда не вредно сказать, зато очень внушает. Ну добавь, что и эта статья не может быть опровержением тезиса ремарка, ведь в тесте "FT" OpenMP быстрее на целых 69%.
А то, что OpenMP, например, в тесте "IS" не медленнее, а С.О.С.Е.Т. (да именно так) на целых 139% — это, конечно, не имеет никакого отношения к делу, и никак не может служить опровержением тезисов remark, который установил безусловные и неоспоримые преимущества разделяемой памяти над передачей сообщений, не проводя никаких тестов, не читая статей, и не делая поиска в интернете . Да здрав-ству-ет ментальное сканирование, результаты которого не опровергнуть ничем! Ура!
Здравствуйте, Gaperton, Вы писали:
G>А то, что OpenMP, например, в тесте "IS" не медленнее, а С.О.С.Е.Т. (да именно так) на целых 139% — это, конечно, не имеет никакого отношения к делу, и никак не может служить опровержением тезисов remark, который установил безусловные и неоспоримые преимущества разделяемой памяти над передачей сообщений, не проводя никаких тестов, не читая статей, и не делая поиска в интернете . Да здрав-ству-ет ментальное сканирование, результаты которого не опровергнуть ничем! Ура!
Ну зачем эти устаревшие ужасы! Ментальное сканирование, скажешь тоже... Кто там будет копаться в этих твоих потемках, отделяя детские комплексы от урматов? См. Minority Report — наши специалисты уже предсказали, что ты проиграешь этот спор в середине 2009.
З.Ы.: Если серьезно, то незачем подкалывать ремарка. Он честно старается выяснить истину. Позитивным моментом в этой драке на табуретках является то, что вы притаскиваете интересные ссылки, до которых большинство читателей бы сами не дорыли. А вот взаимное ущемление самолюбий — момент безусловно негативный.
Лично мне как раз интересно, есть ли способ выбрать одну модель многозадачности, которая бы показывала оптимальную производительность на широком классе задач.
Или хотя бы понять границы оптимальности для каждой из моделей.
А интересно мне это потому, что в последние годы я регулярно наблюдаю, как "интуитивно оптимальные" решения прогибаются под напором "очевидно неоптимальных".
Когда Java с очевидно тормозным GC рвет на веб-сервере плюсы как тузик грелку.
Когда корявый код, сгенерированный VC++, на 30% уделывает по производительности красивый код, написанный вручную ассемблерщиком.
Когда ось, не использующая аппаратную изоляцию процессов, уделывает про IPC промышленные оси, использующие x86 на полную катушку.
Когда векторный UI на HTML рвет по производительности классику на comctl32.
И так далее.
Теперь мне интересно, сможет ли "очевидно тормозная" динамика порвать "интуитивно быструю" статику.
И сможет ли "очевидно тормозной обмен сообщениями" порвать "интуитивно быструю" разделяемую память.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Лично мне как раз интересно, есть ли способ выбрать одну модель многозадачности, которая бы показывала оптимальную производительность на широком классе задач.
There is no silver bullet yet
Все зависит от того, какой класс задач ты рассматриваешь. Я их разделяю на distributed concurrency и non-distributed concurrency. Для первого я бы однозначно выбрал erlang или схожую message-passing actor model.
Для второго, конечно, тоже можно это же самое выбрать, более того erlang только такую модель и предоставляет. Но лично мне это на данный момент кажется неоправданным по нескольким причинам: усложненная модель программирования, снижение эффективности и снижение гибкости. Поэтому я бы выбрал immutability by default, agents & STM (см clojure).
Lisp is not dead. It’s just the URL that has changed: http://clojure.org
G>Я отлично знаю, что я говорю. И если бы ты внимательно читал, что пишут, то понял бы, это не я доказываю, что сообщения быстрее. Это remark доказывает, что разделяемая память быстрее, и обладает какими-то преимуществами. Разница понятна? Понятно, что это не обратные тезисы, получаемые отрицанием друг друга? Эта статья — контрпример к его тезису. Так понятнее?
G>Пойми хотя бы, о чем идет спор, и у кого какая позиция, прежде чем влезать — сэкономишь всем время. Ну неохота ни о чем спорить. А то как обычно — навоображали себе идиотизма, приписали его участникам, и давай шашкой махать.
RSDN как обычно жжот. Спорят все команды. Одна команда воображает, будто вторая говорит, что разделяемая память всегда эффективнее сообщений, и, соответственно опровергает его. Вторая команда воображает, что первая утверждает, что сообщения всегда эффективнее разделяемой памяти и тоже опровергает его. Единственное в чем все спорщики сходятся — это в игнорировании аргументов друг друга
Здравствуйте, Gaperton, Вы писали:
G>Понятно, то есть, тебе хочется докопаться.
Мимо.
G>>>Если бы ты это сделал, то увидел бы вывод авторов статьи в его начале, что их исследование показало, что далеко не очевидно, что OpenMP дает лучшую производительность на SMP машинах, что является прямым опровержением тезиса.
E>>Кстати, в статье рассматриваются три версии программ на OpenMP. Две из них показывают не очень хорошие результаты. Что и позволяет авторам говорить о неочевидности того, что OpenMP является залогом успеха. Зато третья версия уделывает MPI. Что не позволяет использовать данную статью в качестве опровержения тезисов remark-а.
G>Для опровержения тезисов ремарка вполне достаточно одного примера, где "сообщения" показывают лучший результат, а тут их два.
См. ниже.
G>Еще раз, приведу два тезиса:
G>remark: "разделяемая память" имеет преимущества, которые безвозвратно и необходимо утрачиваются при применении message passing style.
Разделяемая память будет иметь приемущества в некоторых ситуацяиях на HT/CMT/HWT, multicore, SMP, SMP-NUMA. И тут она может дать приемущества как по скорости так и по латентности. Особенно целесообразна разделяемая память для небольших операций.
Т.е. remark утверждает, что в некоторых случаях, но не в 100% случаев, разделяемая память будет иметь преимущества. Для доказательства этого тезиса, как я наивно полагал, достаточно привести пример случая, когда это преимущество доказано экспериментально. Такое доказательство приведено в упомянутой тобой статье.
Однако, если бы remark утверждал, что разделяемая память всегда имеет преимущество, тогда было бы достаточно всего лишь одного контрпримера для его опровержения. Но remark этого не утверждает. А вот какие тезисы ему приписываешь ты -- это совсем другая история.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Да? А наши источники говорят, что я давно его выиграл, только кое-кому очень не хочется этого признавать.
S>З.Ы.: Если серьезно, то незачем подкалывать ремарка. Он честно старается выяснить истину. Позитивным моментом в этой драке на табуретках является то, что вы притаскиваете интересные ссылки, до которых большинство читателей бы сами не дорыли. А вот взаимное ущемление самолюбий — момент безусловно негативный.
"Вы" притаскиваете? Я что-то пропустил, помимо Comedy Club в эту субботу? Прости, можно посмотреть на какие-либо ссылки remark, которые он давал не на свои посты?
Он "честно" стараетя выяснить истину, не соблюдая при этом правила автора тезиса? Гы. Гы. Гы.
S>И сможет ли "очевидно тормозной обмен сообщениями" порвать "интуитивно быструю" разделяемую память.
Ну, мне кажется, ты получил ответ на этот вопрос из последней моей ссылки.
Здравствуйте, yumi, Вы писали:
Y>Для второго, конечно, тоже можно это же самое выбрать, более того erlang только такую модель и предоставляет. Но лично мне это на данный момент кажется неоправданным по нескольким причинам: усложненная модель программирования, снижение эффективности и снижение гибкости. Поэтому я бы выбрал immutability by default, agents & STM (см clojure).
В Эрланге, на самом деле, есть разделяемая память в виде таблиц ets, и mnesia, построенная на их базе. Дело в том, что Эрланг по другим своим характеристикам не подходит для всех задач, его целесообразно в паре с С++ применять.
А в clojure, по всей видимости, нет легких потоков, они тяжелые, что не позволяет полноценно использовать агентов. Хотя, в этом смысле он не хуже остальных языков.
Здравствуйте, Sinclair, Вы писали:
S>Теперь мне интересно, сможет ли "очевидно тормозная" динамика порвать "интуитивно быструю" статику.
Работы по автоматическому выводу типов и "мягким системам типов" стирают четкую грань между статикой и динамикой. Если раньше "статика" была фактически синонимом понятия "аннотации типов", то теперь не так. Теперь разница становится все более тонка и неуловима, а динамика — быстрее и надежнее.
Прям штоб "порвать" — сможет только в том случае, если от динамичности или статичности самой по себе мало что зависит, и все определяют другие факторы, скажем, качество рантайма или алгоритм. Строго говоря, динамика не имеет выраженных преимуществ такого рода, на которых можно было бы ловко сыграть и порвать статику хоть где-то. Или я их упускаю.
Вот в "сообщениях" — они есть. Это асинхронность, именно это свойство позволяет писать почти линейно масштабируемые программы в случае латентных каналов данных. И именно за счет этого свойства MPI — реализации иногда обходят OpenMP. У OpenMP действительно меньшие оверхэд на передачу данных, чем в MPI, но при этом существенно хуже масштабируемость.
А ведь в MPI зело дубово сделано — по одному оперсистемному процессу пускается на аппаратный поток, он на одной кросспроцессной передаче теряет дофига, можно сделать сильно лучше.
При современных тенденциях в области многоядерных процов, я бы поставил на asynchronous message-passing. На четырехкристальном Нехалемном сервере, где должно быть в районе 64 аппаратных потоков, OpenMP будет сосать соску.
Здравствуйте, Gaperton, Вы писали:
G>Прям штоб "порвать" — сможет только в том случае, если от динамичности или статичности самой по себе мало что зависит, и все определяют другие факторы, скажем, качество рантайма или алгоритм. Строго говоря, динамика не имеет выраженных преимуществ такого рода, на которых можно было бы ловко сыграть и порвать статику хоть где-то. Или я их упускаю.
Ну, я в свободное время люблю размышлять "по аналогии". На пальцах можно прикинуть такие соображения (оффтоп, но всё равно остальная часть дискуссии как-то завяла):
Итак, чем (на пальцах) отличается динамика от статики? Наверное, тем, что оно вот как-то так:
public class StaticPerson
{
public string Name { get; set;}
public int Age {get;set;}
}
public class DynamicPerson
{
public object this[string PropName] { get; set} ;
}
Интуитивно сразу понятно, что для первого пёрсона умный компилятор сможет фиксировать расположение полей, и мембер аксессы будут на диво шустрыми:
public static int TotalAge(StaticPerson[] persons)
{
int totalAge = 0;
foreach (var p in persons) totalAge+= p.Age; // здесь мы имеем эффективный косвенный доступ и нативные целочисленные операции
}
Тормозная динамика явно потребует честного просмотра хеш-таблицы и полиморфного сложения на каждой итерации, и очевидным образом пролетит:
public static int TotalAge(DynamicPerson[] persons)
{
object totalAge = 0;
foreach (var p in persons) totalAge = PolymorhicAdd(totalAge, p['Age']); // здесь у нас всё плохо.
}
Зачем тогда вообще нужна эта дурацкая динамика?
Ну, например затем, чтобы мы могли быстро добавлять в Person новые свойства без перекомпиляции зависимого кода (который вообще может разрабатываться неизвестными нам 3rdParty).
Или, например, затем, чтобы редкоиспользуемые свойства не жрали место под свои null значения, ухудшая характеристики тесных циклов вроде обсуждаемого.
В итоге, по факту архитектор, озабоченный этими факторами, искусственно делит Person на две части: статическую, для Well-Known Properties, и динамическую, для всякого редконужного мусора.
public class CombinedPerson
{
public int Age {get;set;}
public object this[string PropName] { get; set} ;
}
Понятно, что эффективность полученного решения тесно связана с практикой применения. Если оказалось, что в конкретном контексте у пёрсона прямо-таки всегда заполнено свойство НомерПаспорта, и оно участвует в каких-то многочисленных операциях, то невнесение его в статическую часть — плохо. А если, наоборот, возраст нам малоинтересен, то его наличие в теле объекта раздувает расход памяти.
Такие измышления наталкивают нас на идею о том, где же сможет рулить "автотипизация".
Она сможет рулить там, где границу между статикой и динамикой трудно провести заранее. Именно рантайм, исходя из статистики использования, поймёт, какой нужно построить статический тип для некоторых данных. И сможет получить эффективный результирующий код, полностью использующий преимущества статики.
А маловостребованная часть так и останется сидеть в медленной динамике.
Вот такие примерно соображения. И это — только про runtime performance.
А основное, конечно, преимущество — это отсутствие необходимости вообще проектировать типы заранее. Просто пишешь код, который работает.
Умный компилятор, джит и фреймворк за тебя найдут те 99% объектов, которые по факту в твоей программе имеют статический тип, и сгенерят статические типы именно для этих объектов. В итоге ты будешь иметь класс Point, работающий с эффективностью дотнетовского struct, но без необходимости ручного описания. То есть речь не о том, чтобы "порвать", а о том, чтобы не получить abstraction penalty.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Глянул.
G>Вот на это в статье глянь. G>Table One: Results for the OpenMP/MPI benchmarks. (winning test is in bold)
Из шести тестов в четырех(!) быстрее оказывается вариант на OpenMP.
G> Давай, начинай сеанс особой, форумной магии — делай из этой статьи вывод, что OpenMP показывает убедительный отрыв.
Самое время, имхо, заговорить о форумной магии. Remark сказал, что в некоторых случаях разделяемая память будет иметь преимущества над обменом сообщениями. После чего разговор был переведен на сравнение OpenMP и MPI на некоторых вычислительных задачах (в большинстве которых, как ни странно OpenMP таки выигрывает).
Собственно, неприятное впечатления производят две вещи:
1. Сам перевод разговора о преимуществах/недостатках разделяемой памяти только в плоскость OpenMP и MPI. Тогда как на разделямой памяти можно делать множество разных вещей. Например, в текстовом редакторе может быть буфер, разделяемый между нитью отрисовки, проверки орфографии, автосохранения и в этот же буфер будут вноситься изменения по мере реакции на действия пользователя. На разделяемой памяти могут быть реализованы различные таблицы маршрутизации трафика, с большим количеством нитей-читателей и одной/двумя нитями-писателями. И т.д.
2. Результаты тестов в приводимых тобой статьях ты же сам извращаешь. По твоим словам выходит, что в большинстве случаев OpenMP варианты медленее MPI, тогда как быстрые версии OpenMP программ в большинстве тестов быстрее MPI. При этом сами эти тесты вызывают сомнения как аргументы в разговоре о достоинствах/недостатках разделяемой памяти. Во-первых, за распаралелливание в MPI полностью отвечает программист, тогда как в OpenMP кроме программиста на качества распаралелливания влияет еще и OpenMP компилятор. И это, во-вторых, поскольку первая статья вообще проводила пример отвратительного качества сгенерированного OpenMP компилятором кода (он был даже медленее последовательного). А во второй статье рассматривается OpenMP компилятор из GCC, которому всего несколько лет отроду и в который не было вложено еще достаточного количества времени и ресурсов по сравнению с теми же реализациями MPI.
G>Да здрав-ству-ет ментальное сканирование, результаты которого не опровергнуть ничем! Ура!
Ну ты на RSDN, пожалуй, самый главный мастер художественного слова. Данная тема служит тому еще одним доказательством.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
G>Кстати, о микроконтроллерах. У кого-то могут остаться иллюзии, что они смогут обогнать компилятор, программируя на ассемблере 8 или 16 битные микроконтроллеры, вроде MSP430 или AVR. Так вот, смогут, если только компилятор не называется IAR. Который дает до 40% выигрыша по сравнению с gcc.
gcc плохо работает с неортогональными архитектурами.
Да вообще никак не работает, если честно. Результат сразу можно выкидывать.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
S>>Теперь мне интересно, сможет ли "очевидно тормозная" динамика порвать "интуитивно быструю" статику. G>Работы по автоматическому выводу типов и "мягким системам типов" стирают четкую грань между статикой и динамикой.
А зависимые типы снова её рисуют (там вывод невозможен).
G> Если раньше "статика" была фактически синонимом понятия "аннотации типов", то теперь не так. Теперь разница становится все более тонка и неуловима, а динамика — быстрее и надежнее.
Зависимые типы снова воздвигают знамя аннотации типов, заново увеличивают пропасть и задают новые границы по быстроте и надёжности.
Или хотя бы по надёжности.
G>Прям штоб "порвать" — сможет только в том случае, если от динамичности или статичности самой по себе мало что зависит, и все определяют другие факторы, скажем, качество рантайма или алгоритм. Строго говоря, динамика не имеет выраженных преимуществ такого рода, на которых можно было бы ловко сыграть и порвать статику хоть где-то. Или я их упускаю.
Ж.Е.Л.Е.З.О.
Которое Hardware в VHDL.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Здравствуйте, eao197, Вы писали:
G>>Да что ты говоришь, дорогой. Прям все совсем-пресовсем не так, да?
E>Да, в первой статье прямо говорится, что хорошо оптимизированная OpenMP программа обгоняет хорошо оптимизированную MPI программу.
В первой статье прямо говорится, что это абсолютно не очевидно, что можно получить лучшую производительность при помощи OpenMP.
G>>Вот на это в статье глянь. G>>Table One: Results for the OpenMP/MPI benchmarks. (winning test is in bold)
E>Из шести тестов в четырех(!) быстрее оказывается вариант на OpenMP.
Ой ли. А давай посмотрим, что конкретно кроется за словом "быстрее".
2%, 7%, 9%, и 69% — тесты с выигрышем OpenMP. Значимый отрыв только в одном тесте. 2% — это вообще не смешно, а что такое 9% — ну вместо минуты займет у тебя расчет 55 секунд. Для вашей пенисометрии это может быть и значимый отрыв, но мне, честно, на такую разницу плевать — что есть она, что нет.
27% и 139% — тесты с выигрышем MPI. Значимый отрыв в двух тестах.
Я весь внимание — все еще жду как ты будешь делать вывод о преимуществах разделяемой памяти.
G>> Давай, начинай сеанс особой, форумной магии — делай из этой статьи вывод, что OpenMP показывает убедительный отрыв.
E>Самое время, имхо, заговорить о форумной магии. Remark сказал, что в некоторых случаях разделяемая память будет иметь преимущества над обменом сообщениями.
Началось все с того, что я сказал, что модель asynchoronous message passing лишен недостатков, свойственной модели разделяемой [мутабельной] памяти. Remark влез с комментариями, что я, мол, недостаточно честен, и мне стоило бы сказать, что она лишена еще и преимуществ разделяемой памяти. Пересказывая вкратце дальнейшую дискуссию, я не согласился с тем, что с моей стороны было бы честнее утверждать то, что мне далеко не очевидно, и предложил remark-у, раз ему так хочется — озвучить эти преимущества, о которых он говорит, а потом обосновать их наличие. Что remark делать отказался, предложив мне опровергнуть их отсутствие.
E> После чего разговор был переведен на сравнение OpenMP и MPI на некоторых вычислительных задачах...
После чего я напомнил remark-у о том, что тезис доказывает тот, кто его выдвигает, и, для демонстрации того, что его тезис далеко не так очевиден, дал ему сравнение стиля asynchronous message passing и shared memory на одной и той же программе. Авторы статьи прям такой вывод и сделали — "мы продемонстрировали, что нихрена не очевидно преимущество OpenMP".
Что очень сильно не понравилось remark, и он перешел на мат. Ну как же, он же хотел языком почесать да Гапертону поуказывать, что тому следует говорить, а что не следует, а тут вдруг получается что нарисовался какой-то пример с MPI с OpenMP, про которые он никогда не слышал, и у него вдруг вырисовывается отличная перспектива оказаться в дураках.
E> (в большинстве которых, как ни странно OpenMP таки выигрывает).
Как ни странно, вы с remark думаете, что лучше авторов исследования знаете, какие выводы надо из них делать. Ну все прям идиоты кругом полные. Меж тем, из обоих сравнений следует, как и признали авторы обеих статей, что далеко не очевидно, что OpenMP дает преимущество даже на общей памяти.
E>Собственно, неприятное впечатления производят две вещи:
E>1. Сам перевод разговора о преимуществах/недостатках разделяемой памяти только в плоскость OpenMP и MPI. Тогда как на разделямой памяти можно делать множество разных вещей.
На сообщениях также можно сделать много разных вещей, и работаеть это будет гораздо быстрее, чем MPI, который налетает на кросс-процессный маралинг работая на SMP. Выбор MPI и OpenMP очевиден, так как по ним накоплена большая практика применения, и есть бенчмарки, позволяющие делать сравнения на одинаковых задачах.
В любом случае, я нахожу эту претензию довольно нелепой. Что тебе неприятно? Перевод разговора с абстрактных рассуждений на конкретику? Валяй, покажи мне другой бенчмарк, который лучше. Тот, что ты показал — ложится на сообщения просто идеально, с ним нет абсолютно никаких проблем. Ну, или объясни, чем эти бенчмарки плохи.
E>2. Результаты тестов в приводимых тобой статьях ты же сам извращаешь.
Кстати, давай ты объяснишь мне, с цитатами, как именно я извращаю результаты тестов, цитируя тесты статей.
E>По твоим словам выходит, что в большинстве случаев OpenMP варианты медленее MPI, тогда как быстрые версии OpenMP программ в большинстве тестов быстрее MPI.
Что в твоей голове выходит по моим словам, я могу только догадываться — там могут самые разные чудеса происходить. По моим словам, и по мнению авторов статей, выходит, что тесты не подтверждают выраженного преимущества OpenMP.
E>При этом сами эти тесты вызывают сомнения как аргументы в разговоре о достоинствах/недостатках разделяемой памяти. Во-первых, за распаралелливание в MPI полностью отвечает программист, тогда как в OpenMP кроме программиста на качества распаралелливания влияет еще и OpenMP компилятор.
В OpenMP программист может нашпиговать код "прагмами", что весьма сильно влияет на распараллеливание.
E>И это, во-вторых, поскольку первая статья вообще проводила пример отвратительного качества сгенерированного OpenMP компилятором кода (он был даже медленее последовательного). А во второй статье рассматривается OpenMP компилятор из GCC, которому всего несколько лет отроду и в который не было вложено еще достаточного количества времени и ресурсов по сравнению с теми же реализациями MPI.
Во второй статье примеры MPI и OpenMP компилируется одним и тем же компилятором. Так что они находятся в равных условиях.
G>>Да здрав-ству-ет ментальное сканирование, результаты которого не опровергнуть ничем! Ура!
E>Ну ты на RSDN, пожалуй, самый главный мастер художественного слова. Данная тема служит тому еще одним доказательством.
А ты им, пожалуй, не являешься. Что еще раз подтверждается данной темой.
Ты на личности переходить прекратишь? Или так сильно неймется, что это никак сделать нельзя?
Здравствуйте, Gaperton, Вы писали:
G>>>Да что ты говоришь, дорогой. Прям все совсем-пресовсем не так, да?
E>>Да, в первой статье прямо говорится, что хорошо оптимизированная OpenMP программа обгоняет хорошо оптимизированную MPI программу.
G>В первой статье прямо говорится, что это абсолютно не очевидно, что можно получить лучшую производительность при помощи OpenMP.
А здесь никто и не утверждал, что OpenMP всегда будет быстрее MPI. Так же как никто и не утверждал, что разделяемая память всегда имеет преимущества над обменом сообщений. Так что бесполезно акцентировать внимание на "не очевидно", это и так понятно.
G>Ой ли. А давай посмотрим, что конкретно кроется за словом "быстрее".
Быстрее -- это быстрее. Причем в обоих из указаных тобой статьях. То, что для тебя 2% или 9% не делают погоды -- это частности, никак не влияющие на опубликованные в статьях результаты.
G>27% и 139% — тесты с выигрышем MPI. Значимый отрыв в двух тестах.
Значимый. В двух. Кто-то против этого?
G>Я весь внимание — все еще жду как ты будешь делать вывод о преимуществах разделяемой памяти.
MPI решения не могут нивелировать те 2%, 7% или 9% процентов. Хотят, но не могут. Видимо, из-за того, что у разделяемой памяти нет никаких преимуществ вообще. Ну совсем.
E>>Самое время, имхо, заговорить о форумной магии. Remark сказал, что в некоторых случаях разделяемая память будет иметь преимущества над обменом сообщениями.
G>Началось все с того, что я сказал, что модель asynchoronous message passing лишен недостатков, свойственной модели разделяемой [мутабельной] памяти. Remark влез с комментариями, что я, мол, недостаточно честен, и мне стоило бы сказать, что она лишена еще и преимуществ разделяемой памяти. Пересказывая вкратце дальнейшую дискуссию, я не согласился с тем, что с моей стороны было бы честнее утверждать то, что мне далеко не очевидно, и предложил remark-у, раз ему так хочется — озвучить эти преимущества, о которых он говорит, а потом обосновать их наличие. Что remark делать отказался, предложив мне опровергнуть их отсутствие.
Сухой остаток из вашей баталии в том, что remark высказал утверждение, что в ряде случаев разделяемая память будет иметь преимущества. Но не доказал этого. Ты высказал контрпримеры, которые по твоему мнению должны показывать обратное. Но приведенные тобой примеры больше согласуются с утверждением remark-а, чем опровергают его. Так что никто из вас не доказал своей правоты.
Что до меня, то я не высказывал согласия ни с remark-ом, ни с тобой. Но в разговор меня заставила вмешаться первая статья, которую ты настойчиво и, с моей точки зрения некорректно, приводил как доказательство своей правоты.
G>Меж тем, из обоих сравнений следует, как и признали авторы обеих статей, что далеко не очевидно, что OpenMP дает преимущество даже на общей памяти.
Еще раз: я не помню, чтобы здесь кто-то утверждал, что это очевидно. Более того, никто кроме тебя не приводил здесь OpenMP как эталонный пример распараллеливания работы на основе общей памяти.
E>>1. Сам перевод разговора о преимуществах/недостатках разделяемой памяти только в плоскость OpenMP и MPI. Тогда как на разделямой памяти можно делать множество разных вещей.
G>Тот, что ты показал — ложится на сообщения просто идеально, с ним нет абсолютно никаких проблем.
Где можно посмотреть на его решение на сообщениях?
G>Ну, или объясни, чем эти бенчмарки плохи.
См. ниже.
G>Кстати, давай ты объяснишь мне, с цитатами, как именно я извращаю результаты тестов, цитируя тесты статей.
См. ниже.
G>Что в твоей голове выходит по моим словам, я могу только догадываться — там могут самые разные чудеса происходить. По моим словам, и по мнению авторов статей, выходит, что тесты не подтверждают выраженного преимущества OpenMP.
Давай не ставить тождества между твоими выводами и мнением авторов статей. Статья первая:
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 modification. 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.
И затем в заключении авторы говорят, что хотя не очевидно, что OpenMP может дать преимущества, они все таки эти преимущества получили:
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.
Вторая статья:
If you want your application to be portable on clusters and SMP machines, MPI might be the
best solution. If, however, you do not envision using more than eight or sixteen cores, then
OpenMP is probably one of your best choices if the benchmarks point in that direction. From a
conceptual standpoint, those with experience in both paradigms state that using OpenMP and
MPI provide a similar learning curve and nuance level. There are no shortcuts or free lunches
with OpenMP, or MPI for that matter.
Так что обе статьи говорят вполне ожидаемые вещи: получение преимуществ с помощью OpenMP вовсе не гарантировано (не очевидно, если тебе так больше нравится), но временами OpenMP будет наилучшим выбором.
Что полностью соответствует утверждению remark-а о том, что разделяемая память будет иметь преимущества в некоторых случаях.
Соответственно, если такие случаи есть (а они есть, судя по результатам измерений), то в этих случаях механизм обмена сообщениями лишается преимуществ, которые имеет разделяемая память. О чем опять-таки remark и говорил, как о более честном, с его точки зрения, освящении достоинств обмена сообщениями.
E>>При этом сами эти тесты вызывают сомнения как аргументы в разговоре о достоинствах/недостатках разделяемой памяти. Во-первых, за распаралелливание в MPI полностью отвечает программист, тогда как в OpenMP кроме программиста на качества распаралелливания влияет еще и OpenMP компилятор.
G>В OpenMP программист может нашпиговать код "прагмами", что весьма сильно влияет на распараллеливание.
Так ведь я и сказал "кроме программиста". Программист ставит прагмы, а что из них получится -- это уж как разработчик OpenMP компилятора постарался. И, как видно из тех же статей, не всегда старался.
G>Во второй статье примеры MPI и OpenMP компилируется одним и тем же компилятором. Так что они находятся в равных условиях.
То, что это один компилятор ничего не решает. Решает качество OpenMP компилятора. Как тебе указал твой соратник, Сергей Зефиров, качество gcc не сильно выше плинтуса.
E>>Ну ты на RSDN, пожалуй, самый главный мастер художественного слова. Данная тема служит тому еще одним доказательством.
G>А ты им, пожалуй, не являешься. Что еще раз подтверждается данной темой.
У меня нет классического образования, зато воспитание хорошее.
G>Ты на личности переходить прекратишь?
В данной теме у меня еще не было случая перейти на личности.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, Gaperton, Вы писали:
E>>Самое время, имхо, заговорить о форумной магии. Remark сказал, что в некоторых случаях разделяемая память будет иметь преимущества над обменом сообщениями.
G>Началось все с того, что я сказал, что модель asynchoronous message passing лишен недостатков, свойственной модели разделяемой [мутабельной] памяти. Remark влез с комментариями, что я, мол, недостаточно честен, и мне стоило бы сказать, что она лишена еще и преимуществ разделяемой памяти. Пересказывая вкратце дальнейшую дискуссию, я не согласился с тем, что с моей стороны было бы честнее утверждать то, что мне далеко не очевидно, и предложил remark-у, раз ему так хочется — озвучить эти преимущества, о которых он говорит, а потом обосновать их наличие. Что remark делать отказался, предложив мне опровергнуть их отсутствие.
E>> После чего разговор был переведен на сравнение OpenMP и MPI на некоторых вычислительных задачах...
....ПОСКИПАНО.....
E>>Ну ты на RSDN, пожалуй, самый главный мастер художественного слова. Данная тема служит тому еще одним доказательством. G>А ты им, пожалуй, не являешься. Что еще раз подтверждается данной темой. G>Ты на личности переходить прекратишь? Или так сильно неймется, что это никак сделать нельзя?
Здравствуйте, AndrewVK, Вы писали:
E>>Т.е. remark утверждает, что в некоторых случаях, но не в 100% случаев, разделяемая память будет иметь преимущества.
AVK>Прокомментируй: AVK>
А уж по поводу ситуации, где нам надо только считать данные — обмен сообщениями (на любых очередях), так и останется медленнее на несколько порядков.
1. Я не могу отвечать за remark-a.
2. Лично я сомневаюсь в оценке "несколько порядков". Имхо, более вероятна разница в один порядок, максимум.
3. Я воспринимаю эту фразу в том же смысле: "в некоторых случаях обмен сообщениями на любых очередях останется медленее на несколько порядков", но не в 100% случаев.
4. В качестве примера такой ситуации я могу привести гипотетический пример с маршрутизацией звонков/sms по номерам телефонов: имеется большая таблица или специальное дерево, с помощью которой по префиксу номера адресата определяется оператор, которому принадлежит адресат. Эта таблица может совместно использоваться несколькими потоками-маршрутизаторами (может быть даже несколькими десятками таких потоков) -- они обращаются к ней только для чтения. И имеется один или два потока, которые на основании какой-то внешней информации время от времени вносят изменения в данную таблицу. Например, если процент успешно обработанных пакетов в канале связи с каким-то операторам падает ниже некоторого уровня, то его трафик переадресуется через других операторов. В данном случае оформление таблицы маршрутизации в виде агента, взаимодействие с которым выполняется только в режиме асинхронного обмена сообщениями, может повысить накладные расходы по сравнению с разделяемой памятью в разы. Только за счет того, что заявки должны складироваться в какой-то очереди, извлекаться оттуда, обрабатываться, ответ должен сохраняться в какой-то другой очереди и т.д.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
E>1. Я не могу отвечать за remark-a.
Ну так и не надо вообще за него тогда впрягаться.
E>3. Я воспринимаю эту фразу в том же смысле: "в некоторых случаях обмен сообщениями на любых очередях останется медленее на несколько порядков", но не в 100% случаев.
Э нет. Вот если бы он сказал именно так, то конечно можно было много воды налить. Но он ясно выразился — "ситуация, где нам надо только считать данные".
E>4. В качестве примера такой ситуации
У рыбы блох нет, а вот если бы были ...
... << RSDN@Home 1.2.0 alpha 4 rev. 1120 on Windows Vista 6.0.6001.65536>>
