OberonCore
https://forum.oberoncore.ru/

Параллелизм
https://forum.oberoncore.ru/viewtopic.php?f=27&t=4557		 Страница 2 из 2
Автор:  Kemet [ Понедельник, 21 Октябрь, 2013 14:03 ]
Заголовок сообщения:  Re: Параллелизм
Madzi писал(а):
Для реал-тайм и хард-реал-тайм задач сборщик мусора использовать запрещено. Т.е. если объект имеет директиву
Код:
{realtime}
, то модуль не скомпилируется если у объекта есть выделение/удаление динамической памяти.

Это также неверно - сущности реального времени могут иметь динамические элементы, т.е. ссылочные данные, для которых требуется выделение динамической памяти, если эти ссылочные данные также относятся к сущностям реальномго времени.
Автор:  Борис Рюмшин [ Понедельник, 21 Октябрь, 2013 14:40 ]
Заголовок сообщения:  Re: Параллелизм
Kemet безусловно прав. А "переключения контекстов" не происходит в другом смысле: между кольцами защиты. Все потоки работают на одном уровне защиты, а разграничение как раз и обеспечивается языком.
Автор:  Александр Ильин [ Понедельник, 21 Октябрь, 2013 15:05 ]
Заголовок сообщения:  Re: Параллелизм
То есть, у каждого объекта свой стек?
Автор:  Kemet [ Понедельник, 21 Октябрь, 2013 15:10 ]
Заголовок сообщения:  Re: Параллелизм
Александр Ильин писал(а):
То есть, у каждого объекта свой стек?
У каждого Активного Объекта - да.
Автор:  PSV100 [ Пятница, 21 Февраль, 2014 18:50 ]
Заголовок сообщения:  Re: Параллелизм
Rifat писал(а):
...
Меня заинтересовала фраза "объектно-ориентированный подход предлагает более эффективный способ хорошего использования параллелизма, когда поведение каждого объекта представляется в виде отдельного процесса" и у меня есть несколько вопросов:
1) реализован ли данный подход где-нибудь?
2) если да, то позволяет ли данный подход формально доказывать корректность программ?
3) если не позволяет, то есть ли другие методы параллелизма, которые можно реализовать и при этом формально доказывать корректность таких программ.


Скорее всего, речь идёт об агентном программировании (или "акторы" и т.п.), которые также могут быть реализованы не только на основе ООП (несмотря на возможные заявления, что самые "эффективные" агенты только в ООП). Основные достоинства: относительная лёгкость в понимании самой парадигмы, в немалых случаях приемлемые потери от накладных расходов, есть возможность для широкой декомпозиции решаемых задач. А также нередко в качестве доводов "ЗА" указывают на однородность подхода (и, в целом, одинаковость кода) как для "внутренней параллельности", так и для распределенного взаимодействия программ. И в системах а-ля Erlang "акторы" могут быть легко перенесены из монолитного сервера приложений по разным серверам.

Но есть и особенности. Как справедливо выше отметили:
Иван Кузьмицкий писал(а):
Это очень интересное место. Работая с асинхронными взаимодействиями, которые по факту являются параллельными, можно заметить, что детерминированность асинхронных программ легко пропадает.

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

Потенциал определения отправителя сообщений зависит от реализации платформы, а вот некая временная недетерминированность, действительно, имеет неслабый эффект. Вот неплохой пример: Analyzing Singularity Channel Contracts. В публикации речь идёт о косяках разработчиков Singularity, допустивших возможные взаимоблокировки при общении изолированных процессов по средствам каналов, а потенциал блокировок определен через:
Илья Ермаков писал(а):
Если использовать взаимодействия на сообщениях изолированных процессов, то один из методов доказательства корректности - построение модели на какой-нибудь Promela и далее автоматизированный Model-Checking.

Причём применялась именно Promela, аппарат которой (но, всё-таки, ограниченный) основан на темпоральной логике. И, кстати, как можно заметить, введение понятия "состояние" процесса (определяющее, хотя бы, какие именно сообщения процесс может обрабатывать в этом состоянии) уже повышает его детерминированность. И не всегда агентные "фреймворк-платформы" дают инструментарий шире, чем базовые объекты-акторы, "почтовые ящики" да сообщения. В качестве примера "пошире" могу рекомендовать SObjectizer (описание) -- библиотека для С++, где имеются состояния, объединение агентов по группам, массовые рассылки сообщений и многие другие прикладные абстракции (отработанные и отлаженные, что уже даёт больше шансов для корректности организации работы процессов).

Некоторую критику модели процессов на сообщениях даёт основатель Кложуры Rich Hickey, например, здесь пару слов: Identity and State. Кроме того, что сложно организовать корректную работу массы агентов, общающихся между собой только через "почту", но и не всё так однозначно идентично налаживаются процессы внутри приложения и внешне взаимодействующие (к примеру, по сети). Предлагаемая им модель многопоточности на базе STM (software transactional memory, Concurrent Programming) несколько сглаживает шероховатости ориентировки процессов во времени (в т.ч. имеются идентичные модели и для распределенного взаимодействия -- Avout). Основной недостаток технологий поверх STM -- потенциал для эффективной реализации (по производительности, памяти и др.)

Разработчики популярного Disruptor-а затронули ещё один важный аспект агентов/акторов: при попытках внедрить подобную модель они столкнулись с тем, что техническая обработка самих очередей сообщений съедает много времени, снижая производительность прикладной содержательной работы агентов, что при критических нагрузках неприемлемо. Они применили свою модель на базе одной общей очереди, как кольцевой буфер. Кроме того, достигли минимума каких-либо блокировок, эффективной организации данных в памяти (что архиважно при взаимодействующих ядрах процессора), плюс варианты управления системными потоками (вплоть до фиктивных циклов, лишь бы не отдавать поток ядру ОС). Подробнее: проект, введение, анализ. И важно, что подобная модель по "степени детерминированности" очень близка к однопоточной.

Ещё одна популярная "высоко детерминированная" модель -- парадигма "fork-join". Здесь в начале презентации пример реализации на java (там речь идёт о библиотеке Reducers кложуры, которая использует fork-join), здесь представлены ключевые особенности этой реализации, где главное -- попытка эффективного автоматического распределения нагрузки процессоров/ядер.

Но, многие мэйнстрим-строители платформ забывают, что кроме "автомата" необходимо и ручное управление нагрузкой (а не только то, что таинственным образом вытворяют, к примеру, "параллельные" коллекции, сами решая, как жечь процессоры). Причём простое управление, например, как в языке Julia, где исполняемая процедура/функция привязывается к процессору/ядру простым указанием необязательного передаваемого параметра. И, кстати, сама модель параллельности напоминает типовые "Futures" или "Promises" -- запускается параллельная функция и позже читаются её результаты. В какой-то степени, можно сказать, что Futures/Promises -- концептуально напоминают части или этапы модели fork-join. А модель Disruptor-a, в свою очередь, выглядит как "fork-join в цикле" (условно, т.к. в "производственном конвейере" могут быть несколько производителей сообщений, могут не быть конечных "join"-ов). Вот и проглядывается относительно однородный комлектик моделей как альтернатива агентам, особенно учитывая, что в стиле Futures/Promises организуется распределенное общение программных элементов. При этом, эта связка "по детерминированности" очень близка к однопоточному коду (например, фактически, не требует временных диаграмм), и покрывает широкие потребности.

Таким образом, насчёт моделей агентов/акторов -- не всё так однозначно просто как "более эффективный способ хорошего использования параллелизма". Причём не только с позиции "лёгкости" организации именно корректной асинхронной работы агентов, но и при взгляде на потенциал технической реализации. Также не стоит забывать о важности прямого управления нагрузкой процессоров (кроме автоматического и именно "интеллектуального", и лучше в сотрудничестве с ним), и даже "легковесные", "зеленые" потоки не могут соперничать с полноценной прямой грамотной загрузкой физического ядра процессора без никаких переключений приложением на другие потоки (а модель акторов, в целом, как единое обширное приложение, требует каких-то распределенных переключений потоков, чтобы выравнивать среднюю температуру по больнице. И многие пытающиеся применять зеленые потоки, наслышавшись об успехах Erlang-a, ещё забывают о том, что его потоки, прежде всего, реализуют т.н. "soft realtime" -- ограничивают верхний предел кванта времени для исполняемых инструкций своей виртуальной машины).
Отсюда, не всё так просто и с утверждением:
Н. Вирт писал(а):
...Вообще-то относительно несложно определить, какие части выражения могут вычисляться параллельно. Более важно то, что параллельно могут вычисляться параметры вызываемой функции, если запрещены побочные эффекты - которые не могут возникать в истинно функциональном языке...

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

И ещё одно замечание. Не всегда параллельность оправдывает себя, когда, по факту, не требуются как таковых параллельных действий. В языке Felix (скриптовый язык, дающий на выходе код на С++) есть полезная концепция -- Fibres -- агенты на основе однопоточной кооперативной модели, причём даются некоторые полезные прикладные техники (фактически, здесь агенты -- для задач динамической конфигурации приложений, когда заранее не известно, какой объект с кем будет общаться).

Все модели выше (включая и агентов) не зависят от "объектности", "функциональщины" или "процедурности". Причём это модели "высокого уровня", для организации работы "почтовых ящиков" и иных механизмов нужны "низкоуровневые модели", или прикладные модели могут быть реализованы непосредственно поверх базового уровня. Рекомендую: "Эндрюс Г.Р. Основы многопоточного, параллельного и распределенного программирования", где затронуты многие распространенные технологии (правда не все современные тенденции отражены, включая особенности процессоров, развитие алгоритмов без блокировок и др.).
Автор:  Пётр Кушнир [ Пятница, 21 Февраль, 2014 20:54 ]
Заголовок сообщения:  Re: Параллелизм
Между процессами еще накладнее сообщения передавать.
А что делать, ведь другого пути нет.
Страница 2 из 2 Часовой пояс: UTC + 3 часа
Powered by phpBB® Forum Software © phpBB Group
https://www.phpbb.com/