Здравствуйте, remark, Вы писали:
R>Это уже становится интереснее — хотя бы какие-то объяснения с твоей стороны. Обязательно прочитаю статью. R>НО, во-первых, что бы показать, что у разделяемой памяти нет преимуществ, ты должен приводить ситуации благоприятные для разделяемой памяти, если окажется, что таких ситуаций не удаётся найти или по всех них разделяемая память проигрывает, тогда возможно у неё действительно нет преимуществ.
Тезис доказывает тот, кто его выдвигает. Я говорил, что у разделяемой памяти есть некие недостатки, которых модель с
сообщениями лишена. Это я готов доказать.
Ты взялся спорить, и заявил, что у разделяемой памяти есть еще и преимущества. Ты этот тезис и доказывай, что они есть.
R>Приводить же просто какие-то ситуации и показывать на них, что обмен сообщениями оказывается быстрее — бессмысленно. Это никак не показывает, что у разделяемой памяти нет преимуществ.
Это ты должен доказать, что они у разделяемой памяти _есть_, а не я, что их нет. Тезис — твой. Для начала — тебе стоит хотя бы озвучить эти декларируемые преимущества. Скорость им не является — MPI обходит OpenMP во многих случаях даже на SMP.
R>Да, на экзотических распределенных машинах для супер-вычислений разделяемая память С.О.С.Е.Т. С этим никто не спорит. Там просто нет разделяемой памяти. Но это, в принципе, и мало кому интересно. Сколько процентов из нас разрабатывает ПО для распределенных кластеров?
Тесты в данной статье производятся на SMP-машине, а не на распределенном кластере.
R>Для того, что бы показать, что у разделяемой памяти ЕСТЬ преимущества мне НЕ надо обгонять MPI умножение матриц. И уж точно не надо это делать ВНАЧАЛЕ. R>Я надеюсь, что это ты просто специально пытаешь внести некоторые логические ошибки в свои доказательства, что бы доказать свою точку зрения.
Сформулируй мою точку зрения, которую я пытаюсь доказать. Очень любопытно. По-моему, я оппонирую тебе насчет твоего тезиса о якобы имеющихся преимуществах разделяемой памяти, которые необходимо утрачиваются в модели передачи сообщений.
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, RailRoadMan, Вы писали:
RRM>>Можно взглянуть на решение этой задачи с помощью посылки сообщений?
S>То же самое. Один поток владеет этим числом; он раскидывает его остальным потокам, они обрабатывают число, а ему кидают сообщение "прибавь дельту".
Получается 2 посылки сообщений против одной операции над разделяемой памятью. Ну ладно, даже если мы это сведём к одной посылке сообщений (изначальную рассылку убрали — допустим изначальное значение всем уже известно). Что такое посылка/обработка сообщения — это в любом случае одна небольшая операция над разделяемой памятью (добавление в очередь)(если машина с разделяемой памятью) + ещё_что_то (это ещё что-то по моему опыту оказывается не меньше 100 тактов, или больше). А если у нас всё, что мы хотим сделать укладывается в ту же самую одну небольшую операцию над разделяемой памятью, без всякого ещё_что_то. То как обмен сообщенииями может быть быстрее?
Плюс к этому, обмен сообщениями может быть способом остужать данные в кэше. В то время как в модели с разделяемой памятью мы данные не остужаем.
Плюс возможности перегрузок. Представь эта обработка периодическая. И как правильно сказал Gaperton, обмен сообщениями — асинхронный и толерантный к задержкам. Представь 127 ядер непрерывно генерируют эти сообщения для одного агента, успеет он их разгребать? А когда тестировали на нашем 4-ёх ядерном процессоре вроде всё было хорошо...
Здравствуйте, Gaperton, Вы писали:
RRM>>Это немного нечестно предлагать пример оптимизированный под модель обмена соообщениями.
RRM>>Вот другой пример: RRM>>Есть некое число s инициализированное нулем. RRM>>Несколько потоков каждый из которых читает это число и увеличивает на известное только ему значение. Далее поток как-то обрабатывает прочитанное значение.
RRM>>Можно взглянуть на решение этой задачи с помощью посылки сообщений?
G>Пример очень плохой, это совершенно бессмысленный микротест. Потому, что в данном случае очевидно надо воспользоваться коммутативностью и ассоциативностью сложения, и попросить потоки просто прислать свои числа. Если же число зависит от счетчика, то пример некорректен, так как у программы недетерминированное поведение.
Он на то и пример, чтобы быть простым.
Дельта зависит как от полученного числа так и от потока. В этом случае пример корректен, хотя получаемые числа и будут недерерминированы, а кто сказал, что это не то, что мы хотели? Потоки знают, что числа будут случайные.
G>Однако, если ты так хочешь — то пожалуйста. Надо заметить, что операции над числом у тебя сериализованы, то есть потоки выполняют операцию по очереди. После чего, главный поток ждет на барьере. Вот, что у тебя происходит.
Почему по очереди? За единицу времени, один поток может пять раз поработать числом, второй шесть, третий вообще не работал с ним. Потом ситуация изменится. Кроме того потокидолдны получать число каждые раз не только для того чтобы потом обновить но и для дальнейшего использования
Здравствуйте, RailRoadMan, Вы писали:
G>>Кстати, это как, ничего, что твой пример, который "оптимизирован под разделяемую память" — последовательный, и содержит ноль параллелизма?
RRM>А ничего, что в примере до этого (ктр про s и q) не сильно больше?
Ну, вообще-то "чего" . Надо реально параллельные примеры брать, мне кажется. А то немного странно получается, сравнивать модели параллелизма на последовательных программах.
Здравствуйте, Gaperton, Вы писали:
G>Пример очень плохой, это совершенно бессмысленный микротест. Потому, что в данном случае очевидно надо воспользоваться коммутативностью и ассоциативностью сложения, и попросить потоки просто прислать свои числа. Если же число зависит от счетчика, то пример некорректен, так как у программы недетерминированное поведение.
G>Однако, если ты так хочешь — то пожалуйста. Надо заметить, что операции над числом у тебя сериализованы, то есть потоки выполняют операцию по очереди. После чего, главный поток ждет на барьере. Вот, что у тебя происходит.
G>Оптимизированный вариант на сообщениях — процессы worker-ы объединены в линейный список по PID-ам. Последний worker знает PID главного процесса, главный — PID первого. И действие выполняется передачей сообщения по этому кольцу.
Я думаю, RailRoadMan имел в виду ситуацию, когда эта операция это только одна из стадий обработки запроса на сервере — число процессов не детерминировано, времена и частота выполнения этой операции тоже не детерминированы.
Ну, какой тут будет оптимизированный вариант на сообщениях?
Здравствуйте, remark, Вы писали:
R>Здравствуйте, Gaperton, Вы писали:
G>>Пример очень плохой, это совершенно бессмысленный микротест. Потому, что в данном случае очевидно надо воспользоваться коммутативностью и ассоциативностью сложения, и попросить потоки просто прислать свои числа. Если же число зависит от счетчика, то пример некорректен, так как у программы недетерминированное поведение.
G>>Однако, если ты так хочешь — то пожалуйста. Надо заметить, что операции над числом у тебя сериализованы, то есть потоки выполняют операцию по очереди. После чего, главный поток ждет на барьере. Вот, что у тебя происходит.
G>>Оптимизированный вариант на сообщениях — процессы worker-ы объединены в линейный список по PID-ам. Последний worker знает PID главного процесса, главный — PID первого. И действие выполняется передачей сообщения по этому кольцу.
R>Я думаю, RailRoadMan имел в виду ситуацию, когда эта операция это только одна из стадий обработки запроса на сервере — число процессов не детерминировано, времена и частота выполнения этой операции тоже не детерминированы. R>Ну, какой тут будет оптимизированный вариант на сообщениях?
Здравствуйте, RailRoadMan, Вы писали:
G>>Пример очень плохой, это совершенно бессмысленный микротест. Потому, что в данном случае очевидно надо воспользоваться коммутативностью и ассоциативностью сложения, и попросить потоки просто прислать свои числа. Если же число зависит от счетчика, то пример некорректен, так как у программы недетерминированное поведение.
RRM>Он на то и пример, чтобы быть простым.
RRM>Дельта зависит как от полученного числа так и от потока. В этом случае пример корректен, хотя получаемые числа и будут недерерминированы, а кто сказал, что это не то, что мы хотели? Потоки знают, что числа будут случайные.
Если все, что ты хочешь получить, это случайное число, то я выполняю алгоритмическую оптимизацию и убираю все твои потоки.
Разные модели программирования нельзя сравнивать на бессмысленных тестах, потому что применяются разные подходы к декомпозиции алгоритмов. Давай другой пример — осмысленный. Задача, которую надо распараллелить. И посмотрим, что получится.
G>>Однако, если ты так хочешь — то пожалуйста. Надо заметить, что операции над числом у тебя сериализованы, то есть потоки выполняют операцию по очереди. После чего, главный поток ждет на барьере. Вот, что у тебя происходит.
RRM>Почему по очереди? За единицу времени, один поток может пять раз поработать числом, второй шесть, третий вообще не работал с ним. Потом ситуация изменится. Кроме того потокидолдны получать число каждые раз не только для того чтобы потом обновить но и для дальнейшего использования
Чушь полная. Все вычисления сериализованы, и конкурируют за общий ресурс. Это очень плохая программа.
Реальную задачу приведи, и мы ее попараллелим. Для справки, даже умножение матриц отлично на сообщениях параллелится, хотя на первый взгляд это невозможно, и там просто необходима разделяемая память.
Здравствуйте, Gaperton, Вы писали:
G>Здравствуйте, RailRoadMan, Вы писали:
G>>>Кстати, это как, ничего, что твой пример, который "оптимизирован под разделяемую память" — последовательный, и содержит ноль параллелизма?
RRM>>А ничего, что в примере до этого (ктр про s и q) не сильно больше?
G>Ну, вообще-то "чего" . Надо реально параллельные примеры брать, мне кажется. А то немного странно получается, сравнивать модели параллелизма на последовательных программах.
Ну если это принципиально, то работа с этим числом лишь малая часть работы потоков в системе. Они вообще независимы, кроме этого числа их больше ничего не связывает.
Практически идеальная ситуация но увы, есть это число и с ним нужно работать именно так как я описал.
Здравствуйте, RailRoadMan, Вы писали:
R>>Я думаю, RailRoadMan имел в виду ситуацию, когда эта операция это только одна из стадий обработки запроса на сервере — число процессов не детерминировано, времена и частота выполнения этой операции тоже не детерминированы. R>>Ну, какой тут будет оптимизированный вариант на сообщениях?
RRM>Именно это и имел в виду
Не знаю, что ты имел в виду и какое отношение это имеет к серверу, потому что описал ты отвратительную реализацию генератора случайных чисел.
Не стесняйся, опиши реальную серверную задачу, а я тебе ее положу на Эрланг, и она отлично заработает. Думаешь, в первый раз?
Здравствуйте, RailRoadMan, Вы писали:
G>>Ну, вообще-то "чего" . Надо реально параллельные примеры брать, мне кажется. А то немного странно получается, сравнивать модели параллелизма на последовательных программах.
RRM>Ну если это принципиально, то работа с этим числом лишь малая часть работы потоков в системе. Они вообще независимы, кроме этого числа их больше ничего не связывает.
Так как у тебя обработка числа все равно фактически последовательная, ее надо перенести в процесс, который владеет числом, и изменить протокол его взаимодействия с worker-ами. Понятно? Так поступит проектировщик, оперируя моделью на сообщениях. Показать тебе, как это будет выглядеть, не зная задачи, как ты понимаешь — невозможно.
G>Реальную задачу приведи, и мы ее попараллелим. Для справки, даже умножение матриц отлично на сообщениях параллелится, хотя на первый взгляд это невозможно, и там просто необходима разделяемая память.
R>Плюс возможности перегрузок. Представь эта обработка периодическая. И как правильно сказал Gaperton, обмен сообщениями — асинхронный и толерантный к задержкам. Представь 127 ядер непрерывно генерируют эти сообщения для одного агента, успеет он их разгребать? А когда тестировали на нашем 4-ёх ядерном процессоре вроде всё было хорошо...
Настоящие программы содержат натуральные способы управления параллелизмом.
Выполнение некоторого этапа зависит от результатов выполнения предыдущего. Если это не так, то это взрывной параллелизм, который возникает, например, при умножении матриц (из O(N^2) данных получается O(N^3) операций).
В dynamic data flow сообществе с этим отлично умеют бороться. Штука называется throttling, успешно применялась ещё в CM-5, по-моему.
Читайте книги, это прикольно.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Здравствуйте, Gaperton, Вы писали:
G>Здравствуйте, RailRoadMan, Вы писали:
R>>>Я думаю, RailRoadMan имел в виду ситуацию, когда эта операция это только одна из стадий обработки запроса на сервере — число процессов не детерминировано, времена и частота выполнения этой операции тоже не детерминированы. R>>>Ну, какой тут будет оптимизированный вариант на сообщениях?
RRM>>Именно это и имел в виду
G>Не знаю, что ты имел в виду и какое отношение это имеет к серверу, потому что описал ты отвратительную реализацию генератора случайных чисел.
Когда нечего сказать — переходят на личности (ну или на оценки примеров).
Я описал совершенно надуманный пример максимально оптимальный для разделения памятию. Это в первую очередь пример.
Готов ты именно его решить на передаче сообщений, что бы получилось эффектичнее чем с разделением памяти?
Да — с удовольствием посмотрю.
Нет — признай, что этом (именно в этом идиотском случае, если так легче) случае разделяемая память рулит.
G>Не стесняйся, опиши реальную серверную задачу, а я тебе ее положу на Эрланг, и она отлично заработает. Думаешь, в первый раз?
Кстати а почему серверную? Stanalone приложение параллельным быть права не имеет?
Здравствуйте, Gaperton, Вы писали:
RRM>>Ну если это принципиально, то работа с этим числом лишь малая часть работы потоков в системе. Они вообще независимы, кроме этого числа их больше ничего не связывает.
G>Так как у тебя обработка числа все равно фактически последовательная, ее надо перенести в процесс, который владеет числом, и изменить протокол его взаимодействия с worker-ами. Понятно? Так поступит проектировщик, оперируя моделью на сообщениях. Показать тебе, как это будет выглядеть, не зная задачи, как ты понимаешь — невозможно.
Да все это понятно. Ты только объясни зачем мне здесь заводить спец поток, ктр будет владеть этим числом. Зачем он мне _тут_ уперся, хватит простейшего кода на atomic функциях и разделяемых данных и все. Да если это erlang то поток будет очень легким, а если нет? Если у меня системные потоки?
Я же _не_ утрердаю, что передача сообщение плохо или не имеет преимуществ. Нет.
Единственно что мы с remark-ом (надеюсь я правильно его понимаю) хотим показать, что _иногда_ разделяемый память может быть лучше.
Здравствуйте, RailRoadMan, Вы писали:
RRM>>>Грамотная реализация мьютекса под SMP даже в случае если невозможности захвата мьютекса не будет сразу блокировать поток, а некоторое время покрутиться на спин локе в юзер моде ожидая быстрого освобождения мьютекса и только если мьютекс не освободится заблокирует поток в ядре. В случае очень коротких блокировок мьютексы могут работать без переходя в ядро для блокировки потока, даже если есть реальная конкуренция между потоками S>>Грамотная реализация очереди будет делать то же самое.
RRM>Опа! Т.е. у нас где-то в очереди будет разделяемый спинлок? Или я не понял мысль?
Опа! Т.е. когда я пишу программу на С++, у меня где-то в объектом файле будут ассемблерные инструкции? Или я не понял мысль?
Здравствуйте, RailRoadMan, Вы писали:
RRM>Когда нечего сказать — переходят на личности (ну или на оценки примеров).
Я ничего не сказал про твою личность. Я сказал, что ты привел в качестве примера отвратительную, неэффективную реализацию генератора случайных чисел. Это — правда, это можно при желании математически доказать.
А вот ты перешел на мою личность, заявив, что мне нечего сказать. Ответный переход на личности с моей стороны, мог бы выглядеть, например, так — для иллюстрации: "иногда слышишь такие глупости, что в ответ действительно мало что можно сказать". Но я ведь тебе этого не говорю, правда? А мог бы.
RRM>Я описал совершенно надуманный пример максимально оптимальный для разделения памятию. Это в первую очередь пример. RRM>Готов ты именно его решить на передаче сообщений, что бы получилось эффектичнее чем с разделением памяти?
Ты не описал вообще никакого примера. Ты предложил нам с Синклером эмулировать разделяемую память на одной переменной поверх сообщений. Что разумеется не получится эффективнее, чем прямое использование разделаемой памяти, и чего ни один нормальный человек, работая с сообщениями, в реальных условиях делать не будет.
RRM>Да — с удовольствием посмотрю. RRM>Нет — признай, что этом (именно в этом идиотском случае, если так легче) случае разделяемая память рулит.
Ну да, если взять плохо написанную программу на разделяемой памяти, да переписывать на сообщениях, эмулируя разделяемую память — станет еще хуже. С этим кто спорит-то?
G>>Не стесняйся, опиши реальную серверную задачу, а я тебе ее положу на Эрланг, и она отлично заработает. Думаешь, в первый раз? RRM>Кстати а почему серверную? Stanalone приложение параллельным быть права не имеет?
Блин, да опиши какую хочешь, мне все равно. Но реальную, чтобы можно было выбирать подход к распараллеливанию.
Здравствуйте, Gaperton, Вы писали:
R>>Это уже становится интереснее — хотя бы какие-то объяснения с твоей стороны. Обязательно прочитаю статью. R>>НО, во-первых, что бы показать, что у разделяемой памяти нет преимуществ, ты должен приводить ситуации благоприятные для разделяемой памяти, если окажется, что таких ситуаций не удаётся найти или по всех них разделяемая память проигрывает, тогда возможно у неё действительно нет преимуществ.
G>Тезис доказывает тот, кто его выдвигает. Я говорил, что у разделяемой памяти есть некие недостатки, которых модель с G>сообщениями лишена. Это я готов доказать.
Это оставим, с этим никто не спорит.
G>Ты взялся спорить, и заявил, что у разделяемой памяти есть еще и преимущества. Ты этот тезис и доказывай, что они есть.
Это что за бред такой? Я сделал утверждение. Если все согласны, то и никто ничего не доказывает. Если кто-то несогласен, то это значит, что он делает обратный тезис, значит оба вольны доказывать свою точку зрения. У тебя, кстати, какая точка зрения? Будь добр высказать её явно. А то за твоей мастерской игрой слов ничего не понятно, начинает складываться такое ощущение, что твоя цель просто бессмысленно поспорить.
Я между прочим, если ты не заметил, или немеренно игнорируешь, как раз доказываю, что разделяемая память имеет приемущества. Краткое содержание предыдущих серий: (1) обмен сообщениями — это как минимум одна модифицирующая операция с разделяемой памятью (добавлние в очередь) + ещё некий оверхед. Это не может быть быстрее чем просто одна модифицирующая операция с разделяемой памятью. По моему опыту — выигрыш как *минимум* 100 тактов, в реальности может быть и 500. Если мы можем обойтись немодифицирующй операцией над разделяемой памятью, то тут обмен сообщениями будет проигрывать на порядки. (2) ФИФО обмен сообщениями склонен остужать данные в кэше. Это системный фактор касающийся производительности, его сложно описать в терминах микробенчмарка. Но именно поэтому те фреймворки могут обойтись ЛИФО обменом реализуют именно его. Большинство же фреймворков НЕ могут обойтись ЛИФО. (3) обмен сообщениями иногда пораждает очень неприятный феномен перегрузок из-за того, что каждый агнет может генерировать неограниченный объём работы для *других* агентов. Врагу не пожелаешь оказаться в такой ситуации, т.к. как исправлять порой просто не понятно. Мне приходилось просто переписывать на разделяемую память. Плюс проявление эффекта зависит от аппаратной платформы.
Ты же ничего не прокомментировал по сути, зато сотряс много воздуха насчёт распределенных кластеров и того, что обмен сообщениями иногда лучше. Все, конечно, рады твоей эрудиции, но она тут не будет объективным аргументом.
Пока некоторые всё ещё пребывают в эйфории от обмена сообщениями, другие уже просто прошли этот этап, увидели и осознали недостатки этого подхода, и положили его свой набор инструментов наравне с другими.
R>>Приводить же просто какие-то ситуации и показывать на них, что обмен сообщениями оказывается быстрее — бессмысленно. Это никак не показывает, что у разделяемой памяти нет преимуществ.
G>Это ты должен доказать, что они у разделяемой памяти _есть_, а не я, что их нет. Тезис — твой.
А твой-то какой тезис в данном контексте? Беспартийный? Просто тусуешься вокруг и бросаешь умные фразы?
G>Для начала — тебе стоит хотя бы озвучить эти декларируемые преимущества. Скорость им не является — MPI обходит OpenMP во многих случаях даже на SMP.
Уже озвучил. Попробуй обращать внимание на то, что и другие пишут.
Я гляжу, мои надежды не оправдались, и ты всё-таки не намеренно вносишь логические ошибки. Если MPI где-то обходит OpenMP, то это не значит, что разделяемая память не имеет преимуществ. Не согласен? И озвучь, кстати, что это за SMP такой, о котором ты говоришь.
R>>Да, на экзотических распределенных машинах для супер-вычислений разделяемая память С.О.С.Е.Т. С этим никто не спорит. Там просто нет разделяемой памяти. Но это, в принципе, и мало кому интересно. Сколько процентов из нас разрабатывает ПО для распределенных кластеров?
G>Тесты в данной статье производятся на SMP-машине, а не на распределенном кластере.
Что это за SMP-то кстати? Для супер-вычислений, с сотней процессоров, c распределеннной памятью и NUMA архитектурой, датирован 2000 годом. Ничего не путаю?
R>>Для того, что бы показать, что у разделяемой памяти ЕСТЬ преимущества мне НЕ надо обгонять MPI умножение матриц. И уж точно не надо это делать ВНАЧАЛЕ. R>>Я надеюсь, что это ты просто специально пытаешь внести некоторые логические ошибки в свои доказательства, что бы доказать свою точку зрения.
G>Сформулируй мою точку зрения, которую я пытаюсь доказать. Очень любопытно. По-моему, я оппонирую тебе насчет твоего тезиса о якобы имеющихся преимуществах разделяемой памяти, которые необходимо утрачиваются в модели передачи сообщений.
Сейчас попробую сформулировать твою точку зрения, которую ты пытаешься доказать: Gaperton — самый крутой и эрудированный, за словом в карман не лезет, аргументы приводит не в тему, но зато сильные, и готов спорить, даже не читая, что пишет оппонент.
Здравствуйте, RailRoadMan, Вы писали:
RRM>Единственно что мы с remark-ом (надеюсь я правильно его понимаю) хотим показать, что _иногда_ разделяемый память может быть лучше.
Пример задачи приведи в подтверждение. Что-нибудь кроме задачи эмуляции разделяемой переменной. Может быть, в реальной задаче я вообще без этой разделяемой переменной обойдусь. А я постараюсь.
Здравствуйте, thesz, Вы писали:
G>>Реальную задачу приведи, и мы ее попараллелим. Для справки, даже умножение матриц отлично на сообщениях параллелится, хотя на первый взгляд это невозможно, и там просто необходима разделяемая память.
T>Вставлю свои пять копеек: http://thesz.mskhug.ru/browser/hiersort/doc/sdd2.pdf
T>Там описано программа умножения матриц для машины динамического потока данных, которая ничего, кроме посылки сообщений, делать не умеет.
ААААААААААА! Вы вместе? Какое это имеет отношение к тому, что разделяемая память имеет (или не имеет) преимущества перед посылкой сообщений на несколько-процессорных и/или многоядерных системах?
Здравствуйте, Gaperton, Вы писали:
G>Здравствуйте, RailRoadMan, Вы писали:
RRM>>Когда нечего сказать — переходят на личности (ну или на оценки примеров).
G>Я ничего не сказал про твою личность. Я сказал, что ты привел в качестве примера отвратительную, неэффективную реализацию генератора случайных чисел. Это — правда, это можно при желании математически доказать.
Ты то, что в скобочках написано прочитал? Ты перешел на оценки пример, что на мой взгляд так же не конструктивно как и переход на личности только в более вежливой форме.
G>А вот ты перешел на мою личность, заявив, что мне нечего сказать. Ответный переход на личности с моей стороны, мог бы выглядеть, например, так — для иллюстрации: "иногда слышишь такие глупости, что в ответ действительно мало что можно сказать". Но я ведь тебе этого не говорю, правда? А мог бы.
. Надо реально параллельные примеры брать, мне кажется. А то немного странно получается, сравнивать модели параллелизма на последовательных программах.
