Здравствуйте, eao197, Вы писали:
E>Здравствуйте, Курилка, Вы писали:
К>>Собственно об этом говорит Джо Армстронг, описывая модель многозадачности в Эрланге.
E>Мне показалось, что конекретно это сообщение об Erlang-е весьма поверхносное, популистское и в большей степени рекламное. Хотя оно и понятно
Факт, конечно
E>К сожалению, там не говорится, что если строить все взаимодействие на сообщениях, то временами получается весьма геморройно. Хотя у меня не Erlang-овский опыт, но все же.
Ну до конкретики тут ой как далеко и конкретных проблем тоже...
E>Так что параллелизм -- это, все таки, не легко.
Дак в жизни вообще мало что легко, если копнуть поглубже и решать реальные задачи
eao197,
К>>Собственно об этом говорит Джо Армстронг, описывая модель многозадачности в Эрланге.
E>Мне показалось, что конекретно это сообщение об Erlang-е весьма поверхносное, популистское и в большей степени рекламное. Хотя оно и понятно
E>К сожалению, там не говорится, что если строить все взаимодействие на сообщениях, то временами получается весьма геморройно. Хотя у меня не Erlang-овский опыт, но все же.
Всё будет круто, но не всегда эффективно.
E>Так что параллелизм -- это, все таки, не легко.
Согласен. Уточню: параллелизм — это нелегко в реализации, и трудности возникают когда идёт борьба за эффективность.
Следуя философии Concurrency-Oriented Programming, где каждая самостоятельная сущность должна соответствовать 1:1 процессу в системе, Джо сотоварищи столкнулся с проблемой слишком большого числа одновременно работающих процессов.
...this could not be implemented for a number of reasons.
Firstly, processes take space, even if they are not doing anything. Secondly, any state involved in the connected phase must be replicated across a physical hardware boundary. This is in order to provide for continuous service in the presence of a hardware failure.
...
At the time when the AXD301 software was developed there was an upper limit on the total number of Erlang processes which could run at the same time in the system. This number, while large, was not large enough to allow hundreds of thousands of processes in the system.
Далее, Джо описывает обходной путь, как они уменьшали количество процессов на коннекшн, не самый тривиальный путь надо сказать.
Здравствуйте, Cyberax, Вы писали:
C>Если бы все было так легко...
Хе, на самом деле, все реально — так легко . Читаем ниже.
C>Модель Эраланга работает нормально только если нет разделения данных. А C>если оно есть (например, если несколько потоков работают над одним C>большим массивом) — то все становится плохо.
На практике у тебя в массово-параллельных системах нет общей памяти. Даже в многопроцессорной SMP-системе на Оптеронах общая память выражена через massage-passing поверх гипертранспорта. То же самое применяется в системах с массовым параллелизмом — там разделяемая память физически отсутствует, и эмулируется на посылках сообщений. И ничего.
C>Можно попробовать сделать этот ресурс процессом — но опять получим все C>те же проблемы с блокировками, но уже уровнем выше.
Для этого (разделяемые данные) в Эрланге есть чрезвычайно шустрая Мнезия — распределенная отказоустойчивая база данных реального времени, входящая в состав стандартной библиотеки. Реализована через message-passing, с поддержкой распределенных транзакций, двухфазным и трехфазным коммитом. Все уже давно продумано и украдено до нас.
Здравствуйте, Lazy Cjow Rhrr, Вы писали:
LCR>At the time when the AXD301 software was developed there was an upper limit on the total number of Erlang processes which could run at the same time in the system. This number, while large, was not large enough to allow hundreds of thousands of processes in the system. LCR>[/q]
LCR>Далее, Джо описывает обходной путь, как они уменьшали количество процессов на коннекшн, не самый тривиальный путь надо сказать.
Это в прошлом. Сейчас десятки тысяч процессов на узел — штатная ситуация, с которой обходтся рантайм.
Здравствуйте, Gaperton, Вы писали:
G>Здравствуйте, Lazy Cjow Rhrr, Вы писали:
LCR>>At the time when the AXD301 software was developed there was an upper limit on the total number of Erlang processes which could run at the same time in the system. This number, while large, was not large enough to allow hundreds of thousands of processes in the system. LCR>>[/q]
LCR>>Далее, Джо описывает обходной путь, как они уменьшали количество процессов на коннекшн, не самый тривиальный путь надо сказать.
G>Это в прошлом. Сейчас десятки тысяч процессов на узел — штатная ситуация, с которой обходтся рантайм.
Но идея Джо о том, что прям "все это процесс" — мне представляется довольно больной. Попахивает Смоллтоковским максимализмом в ущерб здравому смыслу (все это объект), с которым, кстати, Джо борется .
Gaperton wrote: > C>Модель Эраланга работает нормально только если нет разделения данных. А > C>если оно есть (например, если несколько потоков работают над одним > C>большим массивом) — то все становится плохо. > На практике у тебя в массово-параллельных системах нет общей памяти. > Даже в многопроцессорной SMP-системе на Оптеронах общая память выражена > через massage-passing поверх гипертранспорта. То же самое применяется в > системах с массовым параллелизмом — там разделяемая память физически > отсутствует, и эмулируется на посылках сообщений. И ничего.
Как выяснилось, мне на практике массовая параллельность не нужна.
Достаточно поддержку двух-четырех процессоров. Хотя сейчас подумываю над
кластеризацией.
> C>Можно попробовать сделать этот ресурс процессом — но опять получим все > C>те же проблемы с блокировками, но уже уровнем выше. > Для этого (разделяемые данные) в Эрланге есть чрезвычайно шустрая Мнезия > — распределенная отказоустойчивая база данных реального времени, > входящая в состав стандартной библиотеки.
Не пойдет. Просто база данных не выдержит — нужны сотни мегабайт данных
в секунду. Причем не просто строк таблиц, а сложных связных структур.
При этом все это связано друг с другом. Причем, как ни странно,
достаточно удобно работать.
Нужен просто другой образ мышления — при работе в Эрланговом стиле
данные делятся на независимые домены, которые меняются только одним
потоком. А в моем случае данные представляются одним куском, которым
никто не владеет эксклюзивно, но потоки при работе временно забирают на
себя владение частью данных.
C>При этом все это связано друг с другом. Причем, как ни странно, C>достаточно удобно работать.
Тут больше похоже на numbercrunching, здесь, я думаю, лучше подойдет какой-нибудь PVM с C++. Как раз поддерживается модель общей памяти поверх SMP и кластеров.
Здравствуйте, Gaperton, Вы писали:
G>Но идея Джо о том, что прям "все это процесс" — мне представляется довольно больной. Попахивает Смоллтоковским максимализмом в ущерб здравому смыслу (все это объект), с которым, кстати, Джо борется .
Таки непонятно, с кем Джо борется: со Смоллтоком, с максимализмом или со здравым смыслом.
Gaperton wrote: > C>struct TraverseNode > C>{ > C> QuadTreeNodePtr q_node; > C> double plausibility; > C> MapNodePtr to_left, to_right; > C> MapVector gradient; > > C> TraverseNode *transformed; > C> bool commit_flag; > C>}; > C> > C>При этом все это связано друг с другом. Причем, как ни странно, > C>достаточно удобно работать. > Тут больше похоже на numbercrunching
Ага, именно он родимый и есть. Причем еще и интерактивный (то есть
работать обязан быстро).
> здесь, я думаю, лучше подойдет какой-нибудь PVM с C++. Как раз > поддерживается модель общей памяти поверх SMP и кластеров.
Вот не знаю поможет ли. Надо думать как распределять доступ к данным.
Здравствуйте, Трурль, Вы писали:
Т>Здравствуйте, Gaperton, Вы писали:
G>>Но идея Джо о том, что прям "все это процесс" — мне представляется довольно больной. Попахивает Смоллтоковским максимализмом в ущерб здравому смыслу (все это объект), с которым, кстати, Джо борется .
Т>Таки непонятно, с кем Джо борется: со Смоллтоком, с максимализмом или со здравым смыслом.
Есть немного. С подходом "все есть объект". У него целая статья на эту тему была. Ну, и со здравым смыслом — он утверждает, что "все есть процесс". С максимализмом? Эт врят ли.
Здравствуйте, Gaperton, Вы писали:
G>Здравствуйте, Gaperton, Вы писали:
G>>Здравствуйте, Lazy Cjow Rhrr, Вы писали:
LCR>>>At the time when the AXD301 software was developed there was an upper limit on the total number of Erlang processes which could run at the same time in the system. This number, while large, was not large enough to allow hundreds of thousands of processes in the system. LCR>>>[/q]
LCR>>>Далее, Джо описывает обходной путь, как они уменьшали количество процессов на коннекшн, не самый тривиальный путь надо сказать.
G>>Это в прошлом. Сейчас десятки тысяч процессов на узел — штатная ситуация, с которой обходтся рантайм.
G>Но идея Джо о том, что прям "все это процесс" — мне представляется довольно больной. Попахивает Смоллтоковским максимализмом в ущерб здравому смыслу (все это объект), с которым, кстати, Джо борется .
Все же, насколько я помню, Джо предлагал выделять в отдельные процессы те сущности в модели, которые соответствуют параллельным активностям в реальной жизни. Т.е. ни о каких процессах типа число, которому посылается сообщение плюс, если уж пытаться строить параллели со Смоллтолком, у него речь не шла. Собственно он пытался предостеречь от предварительной оптимизации, когда начинает казаться что процессов слишком много и появляется желание их сокращать в ущерб простоте и прозрачности модели. Особенно при переходе с другого языка программирования, где понятие "слишком много процессов" существенно отличается от Эрланговского.
Здравствуйте, Mikl Kurkov, Вы писали:
MK>Все же, насколько я помню, Джо предлагал выделять в отдельные процессы те сущности в модели, которые соответствуют параллельным активностям в реальной жизни. Т.е. ни о каких процессах типа число, которому посылается сообщение плюс, если уж пытаться строить параллели со Смоллтолком, у него речь не шла. Собственно он пытался предостеречь от предварительной оптимизации, когда начинает казаться что процессов слишком много и появляется желание их сокращать в ущерб простоте и прозрачности модели. Особенно при переходе с другого языка программирования, где понятие "слишком много процессов" существенно отличается от Эрланговского.
Почитай на его странице его поздние размышления об эрланге. "everything is process", "operator bang-bang", и т.д.
Здравствуйте, Cyberax, Вы писали:
C>Курилка wrote: >> Собственно об этом >> <http://armstrongonsoftware.blogspot.com/2006/08/concurrency-is-easy.html> >> говорит Джо Армстронг, описывая модель многозадачности в Эрланге. >> 2 Moderators: по-моему эта модель совсем не связана с декларативным >> характером языка. C>Если бы все было так легко...
C>Модель Эраланга работает нормально только если нет разделения данных. А C>если оно есть (например, если несколько потоков работают над одним C>большим массивом) — то все становится плохо.
C>Можно попробовать сделать этот ресурс процессом — но опять получим все C>те же проблемы с блокировками, но уже уровнем выше.
Вот здесь что-то вроде ответа от Джо
Хотя тут скорее доводы в пользу того, что разделяемые данные — это плохо
Плюс обещана заметка про транзакционную память, которая должна вроде решать проблемы с блокировками при распараллеливании.
Курилка wrote: > C>Можно попробовать сделать этот ресурс процессом — но опять получим все > C>те же проблемы с блокировками, но уже уровнем выше. > Вот здесь > <http://armstrongonsoftware.blogspot.com/2006/09/why-i-dont-like-shared-memory.html> > что-то вроде ответа от Джо > Хотя тут скорее доводы в пользу того, что разделяемые данные — это плохо
Плохо. Кто же спорит? Вот только без них не обойтись.
> Плюс обещана заметка про транзакционную память, которая должна вроде > решать проблемы с блокировками при распараллеливании.
Слабо верится. Я у себя, фактически, использую как раз транзакционную
память. Проблем с этим не меньше чем с блокировками.
Объекты в программе образуют граф. Представим, что мы создаем
транзакцию, которая захватывает часть графа, внутри этой захваченой
части мы работаем эксклюзивно. Но остаются границы графа — вот тут-то и
начинаются проблемы. Другой процесс может поменять окружение графа так,
что коммит транзакции не будет возможен (или что хуже будет создана
логически неверная ситуация). Так что тут тоже тонких моментов полно.
Здравствуйте, Cyberax, Вы писали:
C>Курилка wrote:
>> Плюс обещана заметка про транзакционную память, которая должна вроде >> решать проблемы с блокировками при распараллеливании. C>Слабо верится. Я у себя, фактически, использую как раз транзакционную C>память. Проблем с этим не меньше чем с блокировками.
Собственно вот обещанная статья. Тож очень простенько и популяризационно.
Но с графами получается и правда хитрая ситуация, согласен. Не бывает серебрянных пуль
Я так понял (верно ли?), что речь идет о том, чтобы не пользоваться разделяемыми переменными, а ограничиться обменом сообщениями?
Грубо говоря, вернуться от потоков к процессам?
Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.
Здравствуйте, AVC, Вы писали:
AVC>Я так понял (верно ли?), что речь идет о том, чтобы не пользоваться разделяемыми переменными, а ограничиться обменом сообщениями? AVC>Грубо говоря, вернуться от потоков к процессам?
Если грубо, то да.
Только процессы Эрланга != процессы ОС и != потоки ОС.
Здравствуйте, Курилка, Вы писали:
AVC>>Я так понял (верно ли?), что речь идет о том, чтобы не пользоваться разделяемыми переменными, а ограничиться обменом сообщениями? AVC>>Грубо говоря, вернуться от потоков к процессам?
К>Если грубо, то да. К>Только процессы Эрланга != процессы ОС и != потоки ОС.
Т.е. без переключения контекстов?
Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.
quicksort =: (($:@(<#[),(=#[),$:@(>#[)) ({~ ?@#)) ^: (1<#)
.
