Здравствуйте, eao197, Вы писали:

G>>Но это мы еще посмотрим — думаю, шансы порвать Питон у меня есть.

E>Питон там давно порвали на британский флаг.

C++ быстрее Эрланга на микротестах, а Питон примерно ему равен, языки одного класса.

G>>1. один поток читает файл, выполняя минимальный лексический разбор — вычленяя записи друг от друга, откладывая всю возможную работу на потом, и раздает их как сообщения воркерам.

E>Ага, вычитывает блоки по несколько Mb, а затем высылает их другим процессам/нитям.
E>А если не высылает, а передает указатель на преаллоцированный буфер, то что это такое, как не использование разделяемой памяти?

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

В Эрланге, например, я воспользуюсь для этого иммутабельными бинарями, и уверяю тебя — на нижнем уровне данные ни разу не скопируются, управление памятью будет практически аналогично С++. При этом, никакой разделяемой памяти, видимой программисту, в Эрланге нет.

G>>Для С++ потребуется толковый класс треда, очереди сообщений, и хороший аллокатор.

E>Победитель просто использует boost::thread без очередей сообщений и аллокатора.

Победитель просто использует С++, и оптимизированный ввод-вывод, потому что программа утыкается в диск, а не в CPU.

Здравствуйте, Gaperton, Вы писали:

G>>>Но это мы еще посмотрим — думаю, шансы порвать Питон у меня есть.

E>>Питон там давно порвали на британский флаг.

G>C++ быстрее Эрланга на микротестах, а Питон примерно ему равен, языки одного класса.

Тогда возникает вопрос:

Не стесняйся, опиши реальную серверную задачу, а я тебе ее положу на Эрланг, и она отлично заработает.

под "отлично" здесь понимается "правильно, но в четыре раза медленее"?

G>Если этот указатель кладется в queue, или в объект с интерйесом queue, то это передача сообщения. И совершенно неважно, указатель там на преаллоцированный буфер, или нет. Важно, что ты не оперируешь явно разделяемой памятью и примитивами синхронизации.

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

G>В Эрланге, например, я воспользуюсь для этого иммутабельными бинарями, и уверяю тебя — на нижнем уровне данные ни разу не скопируются...

Если только процессы не работают на разных нодах.

Здравствуйте, eao197, Вы писали:

E>Здравствуйте, Gaperton, Вы писали:

G>>>>Но это мы еще посмотрим — думаю, шансы порвать Питон у меня есть.

E>>>Питон там давно порвали на британский флаг.

G>>C++ быстрее Эрланга на микротестах, а Питон примерно ему равен, языки одного класса.

E>Тогда возникает вопрос:
E>

E>Не стесняйся, опиши реальную серверную задачу, а я тебе ее положу на Эрланг, и она отлично заработает.

E>под "отлично" здесь понимается "правильно, но в четыре раза медленее"?

Под "отлично" здесь понимается то, что задача хорошо ложится на модель передачи сообщений, а Эрланг служит для иллюстрации.

Если ты не понял, мы здесь говорим о моделях параллелизма, разделяемая память vs на сообщениях, а не о том, что С++ быстрее чем Эрланг. В таком же стиле как на Эрланге, с асинхронными сообщениями, можно писать и на С++. Скажем, при помощи MPI.

G>>Если этот указатель кладется в queue, или в объект с интерйесом queue, то это передача сообщения. И совершенно неважно, указатель там на преаллоцированный буфер, или нет. Важно, что ты не оперируешь явно разделяемой памятью и примитивами синхронизации.

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

Мое представление в целом соответствует взглядам Дийкстры и Хоара, ты уж меня прости, классическое образование — ничего не могу с собой поделать. И комплексовать на тему, что оно у меня не такое, как у тебя — тоже не получается, извини.

Читайте книги, это прикольно. ((с) Зефиров)

G>>В Эрланге, например, я воспользуюсь для этого иммутабельными бинарями, и уверяю тебя — на нижнем уровне данные ни разу не скопируются...

E>Если только процессы не работают на разных нодах.

А что, изобрели способ передавать данные с одного компа на другой без копирования? С этого момента подробнее.

В Эрланге нет абсолютно никакого резона запускать несколько нодов на одной машине — виртуальная машина знает, что такое SMP и умеет его готовить.

Здравствуйте, AndrewVK, Вы писали:

AVK>Здравствуйте, remark, Вы писали:

R>>Это что за бред такой? Я сделал утверждение. Если все согласны, то и никто ничего не доказывает. Если кто-то несогласен, то это значит, что он делает обратный тезис, значит оба вольны доказывать свою точку зрения.

AVK>Афигеть. Ну тогда я делаю тезис — remark пьет по ночам кровь христианских младенцев. Все согласны? Нет? Ну тггда вперед, доказывай

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

Здравствуйте, Gaperton, Вы писали:

C>>Если делать задачи на разделяемой памяти с нормальными явными блокировками и потоками, то тут будет совсем другая картина.
G>Ну да, а на ассемблере можно MS SQL Server написать, а чайной ложкой вырыть тоннель под ЛаМаншем .
Это понятно. Но для многих задач вполне приемлимо.

Умножение матриц на MPI, кстати, тоже относится к выгребанию ложками тоннеля под ЛаМаншем.

C>>>Проблема с message passing в том, что работать с большими массивами меняющихся данных так может быть очень неудобно.
T>>Это как это так это вот?
C>Это когда несколько потоков одновременно работают с одними разделяемыми данными и совместно их меняют.

Как ни странно, но и в этом случае очень часто может быть выявлен высокий параллелизм. И даже зависящий от параметров задачи (O(N) супротив O(1) для ILP).

T>>Неудобно с какой точки зрения?
C>Нужно, фактически, создавать абстракцию разделяемой памяти с помощью сообщений.

Не вижу в этом ничего дурного.

T>>Если что, то анализ потока данных с учётом пространства выполнения программы может помочь в автоматическом преобразовании императивных программ в программы с посылкой сообщений.
C>Это далеко не всегда возможно, да и вообще — это тупой подход.

Скажу так: это возможно во всех практически интересных случаях.

Здравствуйте, Cyberax, Вы писали:

C>Здравствуйте, Gaperton, Вы писали:

C>>>Если делать задачи на разделяемой памяти с нормальными явными блокировками и потоками, то тут будет совсем другая картина.
G>>Ну да, а на ассемблере можно MS SQL Server написать, а чайной ложкой вырыть тоннель под ЛаМаншем .
C>Это понятно. Но для многих задач вполне приемлимо.

На практике в сложной программе добиться хорошего результата оперируя низкоуровневой семафорной моделью очень сложно — это занятие для мазохистов. Хоаровский wait-notify уже гораздо менее error-prone (у Хоара он, правда, как-то по другому назывался, но суть та же). Но я предпочту применять асинхронный обмен сообщениями даже в программах на С++. Удобства существенно превосходят кажущиеся недостатки.

Здесь очень простая вещь, как с ассемблером — теоретически, ты можешь обойти компилятор. На практике — ты проиграешь в производительности, как только задача становится достаточно сложна, по одной простой причине — у тебя не хватит времени его обойти.

C>Умножение матриц на MPI, кстати, тоже относится к выгребанию ложками тоннеля под ЛаМаншем.

Не без того, но — это свойство умножения матриц как задачи, а не привнесенное MPI. Тот же самый блочный алгоритм умножения матриц, который применяется в реализациях на MPI, рулит и на SMP с разделяемой памятью, вообще-то. Он лучше по целому ряду параметров — например, он гуманнее относится к кэшам, и он минимизирует издержки синхронихации.

Локальность данных — она фундаментальна, от нее легчает не только MPI и системам на основе передачи сообщений, но и вообще любой системе с иерархией памяти.

Кстати, умножение матриц в смысле ЛаМанша меркнет по сравнению с взятием обратной матрицы или решением СЛАУ.

Здравствуйте, remark, Вы писали:

R>Вообще, обычно, у меня хорошо с отличением и понимаем шуток... Но ты ставишь меня просто в тупик...
R>Хммм... Ну на самом деле если я посмеюсь: ХА-ХА-ХА-ХА-ХА [небольшой отдых] ХА-ХА-ХА-ХА-ХА
R>то это будет релевантно под оба варианта: если это шутка и нет.

Да? А по-моему, это больше похоже на иллюстрацию к детской поговорке "смех без причины — признак дурачины".

R>Lock-free НЕ имеет никакого отношения ни к производительности, ни к масштабируемости, Lock-free — это ТОЛЬКО о гарантиях системного прогресса:
R>http://rsdn.ru/Forum/message/2930849.1.aspx

Автор: remark
Дата: 27.04.08

Ты правда считаешь себя таким авторитетом в этой теме, что считаешь допустимым ссылаться на собственные посты в форуме как на аргумент в дискуссии?

Тесты показывают преимущество по скорости очередей, написанных в lock-free стиле. Читайте книги, это прикольно. Статьи тоже ничего.

R>Кстати, какой именно алгоритм lock-free очереди ты имеешь в виду?

Поищи сам. Лень.

G>>Хреновый у тебя пример, на самом деле.

R>Хреновый для чего?

У тебя пример, который не имеет отношения ни к достоинствам ни к недостаткам ни передачи сообщений, ни разделяемой памяти. Это просто нерелевантный хреновый пример.

Здравствуйте, Gaperton, Вы писали:

G>Слушай, может вы это в правила внесете, а? В качестве антифлудерского закона? Штоб можно было ссылаться. По-моему, неплохая идея.

Плохо формализуемо. И для особо сложных случаев есть специальный пункт о том, что модератор может забанить на свое усмотрение даже за то, что в правилах не прописано. Есть все таки определенная прелесть в диктатуре

Здравствуйте, Gaperton, Вы писали:

G>Если ты не понял, мы здесь говорим о моделях параллелизма, разделяемая память vs на сообщениях

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

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

Хотя может вы тут с remark-ом как раз обсуждаете затраты на выполнение синхронизации на основе тупых mutex/condition_variable по сравнению с затратами на синхронизацию через очереди сообщений. Тогда дико извиняюсь, не понял этого из предшествующего разговора.

G>В таком же стиле как на Эрланге, с асинхронными сообщениями, можно писать и на С++. Скажем, при помощи MPI.

Тем не менее, что-то не видно, чтобы MPI порвал тот же 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.

Прочитайте хотя бы сами то, что советуете читать другим. Это прикольно.

Здравствуйте, RailRoadMan, Вы писали:
RRM>Опа! Т.е. у нас где-то в очереди будет разделяемый спинлок? Или я не понял мысль?
А то. Поскольку x86 не предлагает низкоуровневых конструкций типа "очередь", то любая реализация очереди так или иначе будет использовать что-то низкоуровневое. Совершенно необязательно при этом использовать тяжелые примитивы и прыгать в режим ядра. Спинлоки и прочие interlocked рулят.

Здравствуйте, RailRoadMan, Вы писали:
RRM>Да все это понятно. Ты только объясни зачем мне здесь заводить спец поток, ктр будет владеть этим числом. Зачем он мне _тут_ уперся, хватит простейшего кода на atomic функциях и разделяемых данных и все.
Видишь ли в чем дело — атомик функции хорошо работают тогда, когда память реально разделена. Ну там, к примеру, речь идет о нескольких ядрах с общим кэшем.
Как только это предположение перестает выполняться, всё становится очень плохо.
Тот "спец поток", который тебе кажется лишним, лучше описывает ситуацию с NUMA.
RRM>Да если это erlang то поток будет очень легким, а если нет? Если у меня системные потоки?
Поясняю: этот "владеющий поток" — всего лишь удобная абстракция. Не нужно трактовать его буквально, как "системный поток". Идея именно в том, что некий фреймворк (например эрланг) предоставляет тебе некий набор абстракций. Ты строишь реализацию из этих абстракций; а затем она автоматически превращается в низкоуровневое решение на конкретной аппаратуре. Если есть возможность — потоки окажутся лёгкими. Если нет — будет поднят системный поток.
RRM>Единственно что мы с remark-ом (надеюсь я правильно его понимаю) хотим показать, что _иногда_ разделяемый память может быть лучше.
Тут важно при обсуждении пользоваться одинаковыми уровнями абстракции. А то получается, что под разделяемой памятью понимается InterlockedIncrement, а под сообщениями — PostThreadMessage. В таком варианте разделяемая память почти всегда победит. А если мы говорим об абстракциях, то оптимизировать программу с разделяемой памятью крайне тяжело — в отличие от программы, написанной в терминах посылки сообщений. Дийкстра неспроста придумал гармонично взаимодействующие процессы
RRM>

Здравствуйте, Gaperton, Вы писали:
G>Вы как дети прям малые. Аппаратно передача сообщений в современных процах НЕ ПОДДЕРЖИВАЕТСЯ. Естественно, она будет реализована посредством разделяемой памяти, ПО ДРУГОМУ на современных процах просто НЕЛЬЗЯ, и я не понимаю, как это в принципе может являться предметом спора. Совсем за идиота собеседника держать не надо, ладно?

Это, кстати, мне до боли напоминает "теорему существования" (c) P.Dvorkin. Там, где он "доказывал", что раз все языки высокого уровня компилируются в ассемблер, значит программа на ассемблере гарантированно не медленнее никакой программы на ЯВУ. Здесь только народ поаккуратнее, и не пытается протолкнуть аналогичное доказательство

Здравствуйте, Sinclair, Вы писали:

RRM>>Да все это понятно. Ты только объясни зачем мне здесь заводить спец поток, ктр будет владеть этим числом. Зачем он мне _тут_ уперся, хватит простейшего кода на atomic функциях и разделяемых данных и все.
S>Видишь ли в чем дело — атомик функции хорошо работают тогда, когда память реально разделена. Ну там, к примеру, речь идет о нескольких ядрах с общим кэшем.
S>Как только это предположение перестает выполняться, всё становится очень плохо.
S>Тот "спец поток", который тебе кажется лишним, лучше описывает ситуацию с NUMA.

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

Но это объяснять бессмысленно, ИМХО, потому что причина спора, мне кажется, в другом. Человек не понимает, что сама структура его программы будет другой, если решать ее в терминах "актеров". И поэтому упорно предлагает в качестве задачи эмулировать мутабельную разделяемую переменную . Все это усугубляется тем, что вся тройка товарищей не делает разницы между разделяемой памятью и моделями синхронизации. Как нам с тобой известно , при использовании разделяемой памяти можно насчитать как минимум штуки 4 разных моделей синхронизации, они же думают, что все ограничивается семафорной моделью, посему и ставят этот знак равенства.

В этих условиях, объяснить что-либо им сложно — они просто не понимают в принципе, что такое "модель синхронизации" — примеров им не хватает для того чтобы эту абстракцию понять (посмотрели бы хотя бы на wait-notify, им уже было бы проще). А чтобы что-то понять, надо для начала признать, что ты что-то не понимаешь — теперь, когда они вошли в polemic mode — им будет очень тяжело это признать.

Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, Gaperton, Вы писали:
G>>Вы как дети прям малые. Аппаратно передача сообщений в современных процах НЕ ПОДДЕРЖИВАЕТСЯ. Естественно, она будет реализована посредством разделяемой памяти, ПО ДРУГОМУ на современных процах просто НЕЛЬЗЯ, и я не понимаю, как это в принципе может являться предметом спора. Совсем за идиота собеседника держать не надо, ладно?

S>Это, кстати, мне до боли напоминает "теорему существования" (c) P.Dvorkin. Там, где он "доказывал", что раз все языки высокого уровня компилируются в ассемблер, значит программа на ассемблере гарантированно не медленнее никакой программы на ЯВУ. Здесь только народ поаккуратнее, и не пытается протолкнуть аналогичное доказательство

Отчего же аккуратнее? Одна такая попытка уже зарегистрирован от remark в соседней ветке.

Дворкина можно было бы отослать на форум геймеров, где они пытались обойти Intel C++ ручным кодированием на ассемблере на короткой программе — я ссылку несколько лет назад давал, — подтверждать свою теорию практикой. Проблема в том, что авторы таких теорем обычно не имеют представления, как на современных процах выполняется программа на ассемблере, и насколько компилятор больше них знает об исполнительном конвейре проца . Вот на том форуме, я помню, народ чуть себе лоб до затылка не расшиб, пытаясь понять (когда попытки обогнать уже бросили), почему более длинный "и корявый" код, сгенеренный IC++, быстрее, чем их "оптимизированный" ассемблер .

Вот, кстати, пример — как бесхитростный gcc компилирует формулу с двумя умножениями для прямолинейного MIPS.
В MIPS, который сам по себе single issue, команда умножения асинхронна. То есть, она занимает один такт, однако результат полагается забирать через несколько тактов из специальной регистровой пары HL.

Так вот, gcc одно умножение заряжает родное, а второе умножение в это время мутит на сдвигах-сложениях. Потому, что так быстрее. Я бы посмотрел на программиста на ассемблере, который попробует обойти gcc под простейший MIPS .

Здравствуйте, AndrewVK, Вы писали:

G>>Слушай, может вы это в правила внесете, а? В качестве антифлудерского закона? Штоб можно было ссылаться. По-моему, неплохая идея.

AVK>Плохо формализуемо. И для особо сложных случаев есть специальный пункт о том, что модератор может забанить на свое усмотрение даже за то, что в правилах не прописано. Есть все таки определенная прелесть в диктатуре

Ничо, пусть имеет статус не запретительный, а рекомендательный. Мне кажется, это хорошая идея, Андрей.

Здравствуйте, Gaperton, Вы писали:

G>Так вот, gcc одно умножение заряжает родное, а второе умножение в это время мутит на сдвигах-сложениях. Потому, что так быстрее. Я бы посмотрел на программиста на ассемблере, который попробует обойти gcc под простейший MIPS .

Кстати, о микроконтроллерах. У кого-то могут остаться иллюзии, что они смогут обогнать компилятор, программируя на ассемблере 8 или 16 битные микроконтроллеры, вроде MSP430 или AVR. Так вот, смогут, если только компилятор не называется IAR. Который дает до 40% выигрыша по сравнению с gcc.

Здравствуйте, eao197, Вы писали:

G>>Если ты не понял, мы здесь говорим о моделях параллелизма, разделяемая память vs на сообщениях

E>Не-а не понял. В указанном мной примере WideFinder наилучшего результата добиваются программы, в которых несколько потоков используют один и тот же буфер для записи данных и для их анализа. Т.е. используют разделяемые между несколькими потоками данные. Стоит только начать передавать каждому потоку копию этого буфера для эксклюзивного пользования -- и кранты, производительность упадет.

"Передача сообщений" как модель синхронизации не говорит, надо тебе передавать копии буферов, или нет. Она даже не утверждает, что нельзя иметь общих данных. Она утверждает, что нельзя иметь мутабельные общие данные, которым требуется синхронизация, и что единственный доступный способ коммуникации параллельных процессов — это асинхронная посылка сообщений с семантикой мэйлбокса. Как именно она реализована — совершенно неважно с точки зрения модели.

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

Да, и это правильно. "Общая память" — это вообще не модель синхронизации. На общей мутабельной памяти можно применять семафоры, wait-notify (близко к мониторам Хоара), рандеву с protected objects как в Аде, или "аккорды", как в Polyphonic C# и joint calculus. На общей иммутабельной памяти отлично живет обмен сообщениями.

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

Чтобы быстро поиметь представление, близкое к моему — открой учебник Танненбаума по оперсистемам (у тебя он есть? Если нет — рекомендую купить), и прочти главу про синхронизацию. Знание — свет. Особенно, если его получение занимает меньше часа. Флуд — тьма.

G>>В таком же стиле как на Эрланге, с асинхронными сообщениями, можно писать и на С++. Скажем, при помощи MPI.

E>Тем не менее, что-то не видно, чтобы MPI порвал тот же OpenMP. Даже из упомянутой тобой статьи.
E>

E>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.

E>Прочитайте хотя бы сами то, что советуете читать другим. Это прикольно.

Я отлично знаю, что я говорю. И если бы ты внимательно читал, что пишут, то понял бы, это не я доказываю, что сообщения быстрее. Это remark доказывает, что разделяемая память быстрее, и обладает какими-то преимуществами. Разница понятна? Понятно, что это не обратные тезисы, получаемые отрицанием друг друга? Эта статья — контрпример к его тезису. Так понятнее?

Пойми хотя бы, о чем идет спор, и у кого какая позиция, прежде чем влезать — сэкономишь всем время. Ну неохота ни о чем спорить. А то как обычно — навоображали себе идиотизма, приписали его участникам, и давай шашкой махать.

Здравствуйте, Gaperton, Вы писали:

G>Я отлично знаю, что я говорю. И если бы ты внимательно читал, что пишут, то понял бы, это не я доказываю, что сообщения быстрее. Это remark доказывает, что разделяемая память быстрее, и обладает какими-то преимуществами. Разница понятна? Понятно, что это не обратные тезисы, получаемые отрицанием друг друга? Эта статья — контрпример к его тезису. Так понятнее?

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

Автор: eao197
Дата: 28.11.08

из нее.

Здравствуйте, eao197, Вы писали:

E>Здравствуйте, Gaperton, Вы писали:

G>>Я отлично знаю, что я говорю. И если бы ты внимательно читал, что пишут, то понял бы, это не я доказываю, что сообщения быстрее. Это remark доказывает, что разделяемая память быстрее, и обладает какими-то преимуществами. Разница понятна? Понятно, что это не обратные тезисы, получаемые отрицанием друг друга? Эта статья — контрпример к его тезису. Так понятнее?

E>Эта статья не может быть контрпримером, поскольку, если бы ты ее прочитал, то увидел бы, что там только в одном случае решение OpenMP SMPD чуть проигрывает MPI. В остальных случаях -- выигрывает, о чем в конце статьи авторы и заявили. Более подробно см. статью или выдержки

Автор: eao197
Дата: 28.11.08

из нее.

Для того, чтобы понять, может эта статья может быть контрпримером, или нет, достаточно внимательно прочитать одну ее часть — Conclusion, выдержки из которого я приводил. Если бы ты это сделал, то увидел бы вывод авторов статьи в его начале, что их исследование показало, что далеко не очевидно, что OpenMP дает лучшую производительность на SMP машинах, что является прямым опровержением тезиса. Мы читать хорошо умеем, уважаемый коллега? Специально для тебя еще раз привожу, и выделяю жирным ключевые фразы, чтобы заметнее были.

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.

Это не опровержение тезиса?

И последнее — тебе правда так сильно докопаться хочется, да?