Библиотека классов для C++, позволяющая создавать приложения, объекты которых взаимодействуют между собой посредством асинхронной посылки сообщений. Это в свою очередь обеспечивает автоматическую распараллеливаемость на несколько процессоров.
Текущий runtime библиотеки обладает следующими характеристиками:
— Позволяет указывать объекты, сообщения для которых обрабатываются в отдельном потоке и объекты, потоки под которые будут распределяться автоматически.
— Подстраивается под загруженность системы и может выделять дополнительные потоки под управляемые объекты. Автоматически выделяет дополнительные потоки если, одни объекты выполняют блокирующие операции, что мешает обработки сообщений для других объектов. После уменьшения нагрузки – удаляет излишние потоки.
Более подробная информация доступна в моем блоге – здесь.
Буду рад, если моя библиотека окажется вам полезна при разработке многопоточных и асинхронных приложений.
Данный релиз связан с существенным улучшением runtime'а. Реализован round-robin алгоритм распределения объектов по вычислительным потокам. Производительность в среднем выросла на 60-70%.
Улучшенный алгоритм планирования
В предыдущей версии алгоритма мной был замечен существенный недостаток. Дело в том, что раньше если рабочий поток (worker) забирал себе объект для обработки сообщений, то он отпускал его только тогда, когда в очереди для данного объекта более не оставалось сообщений. При большом потоке сообщений это могло бы привести к тому, что объект не изымался бы из потока. Как результат, система не могла бы обрабатывать более чем 512 (максимально установленное число потоков) объектов.
Более серьезная ситуация складывалась, когда появлялась необходимость организовать что-то типа «хвостовой рекурсии» из сообщений. В коде это выглядело бы так:
class Listener : public acto::implementation_t {
public:
Listener() : m_active(false)
{
Handler< msg_loop >(&Listener::doLoop);
Handler< msg_start >(&Listener::doStart);
}
private:
void doLoop(acto::actor_t& sender, const msg_loop& msg)
{
if (m_active) {
// Продолжить цикл
self.send(msg_loop());
}
}
void doStart(acto::actor_t& sender, const msg_start& msg)
{
m_active = true;
// Начать цикл
self.send(msg_loop());
}
...
};
Видно, что при получении сообщения msg_loop, объект сразу же ставит себе в очередь точно такое же сообщение. Как результат, очередь никогда не очищается, а объект никогда не освобождает поток.
В новой версии runtime’а каждому объекту на выполнение выделяется определенный интервал времени (около 250 мс), и если обработка сообщений продолжается больше этого интервала, то текущий поток изымает объект, ставит его в конец очереди объектов, требующих обработки, и берет новый объект из начала очереди.
В новом пакете появился тестовый пример – cycles. Он эмитирует вышеописанную ситуацию – запускает 30 объектов, каждый из которых выполняет свой цикл, а по окончании работы сообщает количество проделанных итераций. Если собрать его с новой версией runtime’а, то на консоль будет выведена колонка из 30 цифр, близких друг к другу. А если пример собрать со старой версией, то также будет выведена колонка из 30 цифр, но только несколько из них будут большими, а остальные будут либо нули, либо очень близки к нулю. Это как раз и означает, что большинство объектов ранее просто не получало вычислительных ресурсов для обработки сообщений.
Увеличение производительности
В основном связано с вышеописанным изменением алгоритма, плюс некоторая шлифовка других функций.
Для теста производительности я использовал программу ping-pong (поставляется с библиотекой). В своем блоге я писал, что, ранее показатель производительности составлял около 400 тыс. сообщений/сек, теперь же он составляет в среднем 650-700 тыс. сообщений/сек.
Установка новой версии
Если Вы уже попробовали написать какие-нибудь программы с использованием acto, то для того, чтобы они начали работать с новой версией runtime’а, достаточно заменить папку multiprog – папка с исходниками библиотеки. Также добавился один cpp-файл – worker.cpp, его необходимо будет подключить в проект.
Здравствуйте, remark, Вы писали:
R>E2180 — это двухядерный процессор. Правильно?
Да.
R>з.ы. А ты компилировал в 64 битном режиме?
Да.
R>Интересно было бы просмотреть на масштабируемость системы и на то, насколько эффективно она утилизирует 2 ядра. R>И приведи цифры, какая пропускная способность с этой строчкой и без неё.
Получилось примерно следующее (пока замерял "наглаз", надо будет более автоматизированные тесты написать...)
Программа ping-pong: 50'000 объектов, 50'000 одновременных сообщений, 50 итераций.
pp32x1: 500 тыс. сообщ/сек., колебание — 30 тыс., пиковое значение — 590 тыс.
pp32x2: 700 тыс. сообщ/сек., колебание — 100 тыс., пиковое значение — 826 тыс.
pp64x1: 550 тыс. сообщ/сек., колебание — 10 тыс.
pp64x2: 600 тыс. сообщ/сек., колебание — 50 тыс.
Программа cycles: 30 объектов, задержка 10 сек.
cl32x1: 300 тыс. итераций.
cl32x2: 450 тыс. итераций.
cl64x1: 300 тыс. итераций.
cl64x2: 600 тыс. итераций.
Воощем, видно что производительность растет, хоть и не линейно. Увеличение отклонения на двух ядрах мне думается связанно с тем, что повышается вероятность сталкивания потоков на очередях. Так как в текущем релизе не lock-free очередь, а на критической секции. Связано это с тем, что я еще не доконца разобрался, как правильно реализовать очередь лишенную ABA-проблемы...
Здравствуйте, Стэн, Вы писали:
С>Улучшенный алгоритм планирования
С>В предыдущей версии алгоритма мной был замечен существенный недостаток. Дело в том, что раньше если рабочий поток (worker) забирал себе объект для обработки сообщений, то он отпускал его только тогда, когда в очереди для данного объекта более не оставалось сообщений. При большом потоке сообщений это могло бы привести к тому, что объект не изымался бы из потока. Как результат, система не могла бы обрабатывать более чем 512 (максимально установленное число потоков) объектов.
Если в системе есть ограничение на максимально возможное число потоков, то это может приводить к т.н. system-induced deadlocks. Т.е. в пользовательской программе дедлока нет, но он появляется в работающей программе как артифакт работы ран-тайм системы. Что бы избавиться от system-induced deadlocks надо снять ограничение на число потоков, и создавать их всегда, когда есть необходимость. Хотя скорость создания новых потоков, естественно можно сильно ограничивать с ростом числа потоков.
Такие дедлоки возникают, например, в системах на основе .NET ThreadPool, который имеет верхнее ограничение на число потоков.
Здравствуйте, Стэн, Вы писали:
С>Библиотека классов для C++, позволяющая создавать приложения, объекты которых взаимодействуют между собой посредством асинхронной посылки сообщений. Это в свою очередь обеспечивает автоматическую распараллеливаемость на несколько процессоров.
Подстраивается под загруженность системы и может выделять дополнительные потоки под управляемые объекты, если текущие потоки не справляются с обработкой всех сообщений. Это позволяет продолжать обработку сообщений, даже если часть объектов выполняет сверхдолгие или блокирующие операции. В данной версии установлено ограничение на максимальное число потоков – 512.
А как ты определяешь, что рабочие потоки блокируются? Т.е. когда надо порождать новые рабочие потоки?
Вообще это достаточно фундаметальная проблема, и я не знаю никакого хорошего решения для неё...
Ты так же упомянаешь, что порождаешь новые потоки даже тогда, когда другие рабочие потоки не блокируются, а просто выполняют сверхдолгие операции. Т.е. ты допускаешь 512 активных потоков? Тебе не кажется, что это достаточно губительно скажется на производительности? Оптимальная производительность достигается при 1-2 активных потоках на процессор. В исключительных случаях можно допустить максимум на порядок больше потоков (10), но не больше в 256 раз...
Кстати, ты можешь использовать следующий трюк для существенного снижения давления на память. Т.к. в event-driven приложениях стека фактически нет (в смысле стека функций в традиционном понимании), и на стеке всегда только *одна* функция, которая обрабатывает текущее сообщение, то ты можешь устанавливать размер стека для рабочих потоков, например, в 64 кб, вместо 1 Мб по-умолчанию. Этого должно хватать с лихвой в большинстве приложений. Для приложений, которым не будет хватать этого объёма стека, ты можешь предоставить функцию для перекрытия размера стека. Этот параметр можно вынести опциональным параметром в acto::startup().
Т.о. при 512 потоках будет занято только 32 Мб адресного пространства вместо 512 Мб.
Здравствуйте, Стэн, Вы писали:
С>Библиотека классов для C++, позволяющая создавать приложения, объекты которых взаимодействуют между собой посредством асинхронной посылки сообщений. Это в свою очередь обеспечивает автоматическую распараллеливаемость на несколько процессоров.
Я правильно понимаю, что все сообщения только типа точка-точка, т.е. нельзя отправлять широковещательные сообщения?
Даются ли какие-то гарантии по fifo порядку обработки? Это достаточно критичный момент при реализации бизнес-логики, без каких-либо гарантий по fifo порядку обработки не получится реализовать ничего толкового...
Даются ли какие-то гарантии по возможности вызова сразу нескольких функций обработки сообщений одновременно из разных потоков для управляемых объектов?
Здравствуйте, remark, Вы писали:
R>Я правильно понимаю, что все сообщения только типа точка-точка, т.е. нельзя отправлять широковещательные сообщения?
Да. Я хочу держать ядро как можно более простым и компактным, поэтому нет понятий широковещание и подписка на событие.
Однако эту ситуацию всегда можно разрулить на пользовательском уровне, создав промежуточный объект broadcaster, например, которому посылается сообщение, а он уже пересылает его всем клиентам, у него зарегестрированным.
R>Даются ли какие-то гарантии по fifo порядку обработки? Это достаточно критичный момент при реализации бизнес-логики, без каких-либо гарантий по fifo порядку обработки не получится реализовать ничего толкового...
Да. Сообщение обрабатываются строго в порядке поступления в очередь, а функция actor_t::send сразуже осуществляет постановку. Так в этом примере:
Объекту Calculator вначале будет передано на обработку сообщение msg_init, и только потом msg_calc.
И, конечно-же, порядок сообщений, посланных одновременно, разными объектами в общем случае неопределен.
R>Даются ли какие-то гарантии по возможности вызова сразу нескольких функций обработки сообщений одновременно из разных потоков для управляемых объектов?
Для отдельно взятого объекта гарантируется, что обработчики сообщений не_будут вызываться в разных потоках одновременно.
Re[2]: [ann] act-o – библиотека асинхронного программировани
Здравствуйте, remark, Вы писали:
R>А как ты определяешь, что рабочие потоки блокируются? Т.е. когда надо порождать новые рабочие потоки? R>Вообще это достаточно фундаметальная проблема, и я не знаю никакого хорошего решения для неё...
Есть стек свободных потоков и есть очередь объектов, которым поступили сообщения. Мастер-поток смотрит, что очередь объектов не пуста и проверяет стек свободных потоков. Если есть свободные потоки то берется один поток, из очереди извлекается один объект и назначается потоку. Если же потоков нет, то я ставлю ожидание на пару секунд и если свободных потоков так и не появилось, то создается новый...
R>Ты так же упомянаешь, что порождаешь новые потоки даже тогда, когда другие рабочие потоки не блокируются, а просто выполняют сверхдолгие операции. Т.е. ты допускаешь 512 активных потоков? Тебе не кажется, что это достаточно губительно скажется на производительности? Оптимальная производительность достигается при 1-2 активных потоках на процессор. В исключительных случаях можно допустить максимум на порядок больше потоков (10), но не больше в 256 раз...
Да, я знаю, что это не круто... Это недостаток вышеописанной схемы. Сейчас я активно работаю, чтобы улучшить ее. Но даже в текущей схеме много потоков насоздается только, если сообщения будут посылаться непрерывно с очень большой интенсивностью.
R>Кстати, ты можешь использовать следующий трюк для существенного снижения давления на память. Т.к. в event-driven приложениях стека фактически нет (в смысле стека функций в традиционном понимании), и на стеке всегда только *одна* функция, которая обрабатывает текущее сообщение, то ты можешь устанавливать размер стека для рабочих потоков, например, в 64 кб, вместо 1 Мб по-умолчанию. Этого должно хватать с лихвой в большинстве приложений. Для приложений, которым не будет хватать этого объёма стека, ты можешь предоставить функцию для перекрытия размера стека. Этот параметр можно вынести опциональным параметром в acto::startup(). R>Т.о. при 512 потоках будет занято только 32 Мб адресного пространства вместо 512 Мб.
Спасибо, надо будет просчитать такую возможность...
Re: [ann] act-o – библиотека асинхронного программирования
Здравствуйте, Стэн, Вы писали:
_>>Мне интересно какие способы есть чтобы безболезненноо закрыть _>>программу на основе такой техники. С>А что значит "безболезненно"?
Чтобы и потоки остановились и деструкторы все вызвались. Похоже...
... << RSDN@Home 1.2.0 alpha rev. 784>>
Re[4]: [ann] act-o – библиотека асинхронного программировани
_>Здравствуйте, avp_, Вы писали: _>Ага. Плюс дождаться пока все сообщения из очередей обработаются, _>с учётом того что обработка одного сообщения может породить новые.
У меня сейчас делается так. Объект состоит из заголовка и реализации. Заголовок — acto::core::object_t (внутренний класс) и реализация acto::implementation_t (от него порождаются пользовательские объекты).
Есть специальная функция acto::destroy( obj ). После ее вызова очередь сообщений "закрывается" так что объект больше не может получать сообщения. После того, как все оставшиеся сообщения в очереди будут обработаны, то вызывается деструктор для реализации объекта. После того, как на объект исчезнут все ссылки, то удаляется заголовок.
Соответственно все потоки гарантированно останавливаются, если в системе больше нет объектов.
Вместе с библиотекой поставляется пример ping-pong, так там функции открытия/закрытия программы безболезненно выполняются по многу раз в цикле. Блок кода acto::startup() ... acto::shutdown().
Что касается того, что объект может порождать новые сообщения, то, теоритическии ему можно вначале давать сигнал msg_destroy, а потом ждать, когда он сам отправить какое-то специальное сообщение ядру, и только тогда закрывать очередь...
Re[5]: [ann] act-o – библиотека асинхронного программировани
Здравствуйте, avp_, Вы писали:
_>Ага. Плюс дождаться пока все сообщения из очередей обработаются, _>с учётом того что обработка одного сообщения может породить новые.
Один из вариантов — организовать все очереди в логический круг и запустить по этому кругу специальное сообщение-токен, когда оно сделает 2 полных оборота по пустым очередям — значит сообщений больше нет и не появиться.
Здравствуйте, Стэн, Вы писали:
С>Для теста производительности я использовал программу ping-pong (поставляется с библиотекой). В своем блоге я писал, что, ранее показатель производительности составлял около 400 тыс. сообщений/сек, теперь же он составляет в среднем 650-700 тыс. сообщений/сек.
E2180 — это двухядерный процессор. Правильно?
Интересно было бы просмотреть на масштабируемость системы и на то, насколько эффективно она утилизирует 2 ядра.
Попробуй вначале теста вставить:
SetProcessAffinityMask(GetCurrentProcess(), 1);
что бы привязать все потоки процесса только к первому ядру.
И приведи цифры, какая пропускная способность с этой строчкой и без неё.
Здравствуйте, Стэн, Вы писали:
R>>Интересно было бы просмотреть на масштабируемость системы и на то, насколько эффективно она утилизирует 2 ядра. R>>И приведи цифры, какая пропускная способность с этой строчкой и без неё.
А будет ли поддержка NUMA? Правда у меня нет сейчас доступа к Opteron машине, чтоб посмотреть и погонять...
Здравствуйте, Edge, Вы писали:
E>А будет ли поддержка NUMA? Правда у меня нет сейчас доступа к Opteron машине, чтоб посмотреть и погонять...
Да. С самого начала я ставил себе целью сделать такую библиотеку, которая, предоставляя высокоуровневые абстракции, позволяла бы не думать о потоках, о синхронизациях, о количестве процессоров, но задействовать ресурсы компьютера по-максимуму. NUMA позволяет каждому процессору быстрее обмениваться с памятью, если она для него локальная. Для некоторого класса приложений это может оказаться важным и обойти стороной подобную возможность ускорить их было бы неправильно. Однако пока рано говорить о том, как это будет выглядеть и какие дополнительные абстракции будут предоставлены для поддержки NUMA.
Re[3]: [ann] act-o – библиотека асинхронного программировани
Здравствуйте, Стэн, Вы писали:
С>Здравствуйте, remark, Вы писали:
R>>А как ты определяешь, что рабочие потоки блокируются? Т.е. когда надо порождать новые рабочие потоки? R>>Вообще это достаточно фундаметальная проблема, и я не знаю никакого хорошего решения для неё... С>Есть стек свободных потоков и есть очередь объектов, которым поступили сообщения. Мастер-поток смотрит, что очередь объектов не пуста и проверяет стек свободных потоков. Если есть свободные потоки то берется один поток, из очереди извлекается один объект и назначается потоку. Если же потоков нет, то я ставлю ожидание на пару секунд и если свободных потоков так и не появилось, то создается новый...
Допустим у меня есть 100 агентов, и у каждого по 1 блокируещей операции в очереди. И допустим в шеделере имеется один рабочий поток.
Правильно ли я понимаю, что при условии, что каждая блокирующая операция будет обрабатываться менее, чем за пару секунд, дополнительных рабочих потоков создано не будет? Т.е. все 100 блокирующих операций будут запускаться строго последовательно?
R>>Ты так же упомянаешь, что порождаешь новые потоки даже тогда, когда другие рабочие потоки не блокируются, а просто выполняют сверхдолгие операции. Т.е. ты допускаешь 512 активных потоков? Тебе не кажется, что это достаточно губительно скажется на производительности? Оптимальная производительность достигается при 1-2 активных потоках на процессор. В исключительных случаях можно допустить максимум на порядок больше потоков (10), но не больше в 256 раз... С>Да, я знаю, что это не круто... Это недостаток вышеописанной схемы. Сейчас я активно работаю, чтобы улучшить ее.
Пиши, когда что-нибудь придумаешь
С>Но даже в текущей схеме много потоков насоздается только, если сообщения будут посылаться непрерывно с очень большой интенсивностью.
В этой ситуации, при условии, что операции *не* блокирующие, как раз бы уменьшать кол-во потоков, что бы повысить пропускную способность. А тут получается, что с повышением нагрузки, фреймворк начинает только увеличивать накладные расходы на переключения контекстов и потребление ресурсов (память под потоки), тем самым только усугубляя ситуацию...
R>>Даются ли какие-то гарантии по fifo порядку обработки? Это достаточно критичный момент при реализации бизнес-логики, без каких-либо гарантий по fifo порядку обработки не получится реализовать ничего толкового... С>Да. Сообщение обрабатываются строго в порядке поступления в очередь, а функция actor_t::send сразуже осуществляет постановку. Так в этом примере:
А на какую производительность ты нацеливаешься?
R>>Даются ли какие-то гарантии по возможности вызова сразу нескольких функций обработки сообщений одновременно из разных потоков для управляемых объектов? С>Для отдельно взятого объекта гарантируется, что обработчики сообщений не_будут вызываться в разных потоках одновременно.
R>>>Даются ли какие-то гарантии по возможности вызова сразу нескольких функций обработки сообщений одновременно из разных потоков для управляемых объектов? С>>Для отдельно взятого объекта гарантируется, что обработчики сообщений не_будут вызываться в разных потоках одновременно.
Например, в твоём примере ping-pong проблемы может вызвать актёр Wall. Через него проходит каждое второе сообщение, и он сериализует всю обработку. Допустим на системе с 16 аппаратными потоками, актёры Player могут обрабатываться параллельно и масштабируемо. Но актёр Wall будет обрабатываться только в одном потоке в каждый момент времени. Т.е. производительность системы ограничена скоростью, с которой *один* поток сможет обрабатывать сообщения актёра Wall. Система не масштабируется.
Некоторые варианты решения:
— разрешить обрабатывать сообщения для Wall на разных потоках одновременно
— "партицировать" актёра Wall на много "частей" по кол-ву аппаратных потоков, сообщения для каждой "части" актёра могут обрабатываться параллельно
Здравствуйте, remark, Вы писали:
R>Допустим у меня есть 100 агентов, и у каждого по 1 блокируещей операции в очереди. И допустим в шеделере имеется один рабочий поток. R>Правильно ли я понимаю, что при условии, что каждая блокирующая операция будет обрабатываться менее, чем за пару секунд, дополнительных рабочих потоков создано не будет? Т.е. все 100 блокирующих операций будут запускаться строго последовательно?
Правильный ответ заключается в том, что все зависит от конкретно реализованного алгоритма, а алгоритм может и будет меняться. В версии beta 2.5 применяется следующая схема. Если нет свободных потоков, то мастер-поток ждет заданный интервал времени (начальное значение 2 сек). Если за этот период никакой поток не освободился, то создается новый поток, а значение интервала увеличивается еще на две секунды, и т.д...
R>В этой ситуации, при условии, что операции *не* блокирующие, как раз бы уменьшать кол-во потоков, что бы повысить пропускную способность. А тут получается, что с повышением нагрузки, фреймворк начинает только увеличивать накладные расходы на переключения контекстов и потребление ресурсов (память под потоки), тем самым только усугубляя ситуацию...
С этим согласен. Только как определить, что текщий обработчик сообщения вызвал блокирующую операцию? Если есть такая возможность, то конечно, так будет правильно, а иначе приходится действовать эвристическими методами.
А вообще, смысл библиотеки acto в том, чтобы предоставить удобный асинхронный интерфейс, имея который можно было бы не использовать блокирующие операции.
Re[4]: [ann] act-o – библиотека асинхронного программировани
Здравствуйте, remark, Вы писали:
R>А на какую производительность ты нацеливаешься?
Ну, а какой русский не любит быстрой езды?..
А если конкретно, то я не очень понял вопрос, поэтому отвечу как понял.
Есть вычислительная модель — легкие процессы, которые могут обрабатывать задания (tasks). Отдельно взятый процесс обрабатывает свои задания строго последовательно. Два произвольно взятых процесса обрабатывают свои собственные задания независимо друг от друга, и в общем случае могут делать это параллельно. Такова вычислительная модель. Очень возможно, что есть класс задач, для которых такая модель не очень подходит, так как непроизводительные издержки (создание и пересылка task'ов) могут оказаться пропорциональны или даже превышать полезную нагрузку. Очевидно, что для таких задач необходимо выбирать другую вычислительную модель, и, соответственно, необходимо выбрать какую-то другую библиотеку.
R>Возможно тебе будет интересно поглядеть это обсуждение: R>http://sourceforge.net/mailarchive/message.php?msg_name=op.t2aesuukk4pnxe%40eao197nb3.intervale.ru
Спасибо.
Re[5]: [ann] act-o – библиотека асинхронного программировани
Здравствуйте, remark, Вы писали:
R>Например, в твоём примере ping-pong проблемы может вызвать актёр Wall. Через него проходит каждое второе сообщение, и он сериализует всю обработку. Допустим на системе с 16 аппаратными потоками, актёры Player могут обрабатываться параллельно и масштабируемо. Но актёр Wall будет обрабатываться только в одном потоке в каждый момент времени. Т.е. производительность системы ограничена скоростью, с которой *один* поток сможет обрабатывать сообщения актёра Wall. Система не масштабируется.
R>Некоторые варианты решения: R> — разрешить обрабатывать сообщения для Wall на разных потоках одновременно R> — "партицировать" актёра Wall на много "частей" по кол-ву аппаратных потоков, сообщения для каждой "части" актёра могут обрабатываться параллельно
R>Что думаешь?
Я думаю, что вычислительную модель лучше не трогать. Она проста, понятна и от нее можно ожидать того, что в каждый момент времени, каждый актер может обрабатывать только одно сообщение. Нарушим этот принцип, и я более чем уверен, что очень быстро возникнет ситуация когда — "да, девять полей в объекте могут безопасно обрабатываться в разных потоках, но вот десятое, его бы немножечко мьютексом..."
С самого начала я ставил себе цель уйти от подобных мьютексов, так что я однозначно за второй вариант.
Re[5]: [ann] act-o – библиотека асинхронного программировани
Здравствуйте, Стэн, Вы писали:
С>Здравствуйте, remark, Вы писали:
R>>Допустим у меня есть 100 агентов, и у каждого по 1 блокируещей операции в очереди. И допустим в шеделере имеется один рабочий поток. R>>Правильно ли я понимаю, что при условии, что каждая блокирующая операция будет обрабатываться менее, чем за пару секунд, дополнительных рабочих потоков создано не будет? Т.е. все 100 блокирующих операций будут запускаться строго последовательно? С>Правильный ответ заключается в том, что все зависит от конкретно реализованного алгоритма, а алгоритм может и будет меняться. В версии beta 2.5 применяется следующая схема. Если нет свободных потоков, то мастер-поток ждет заданный интервал времени (начальное значение 2 сек). Если за этот период никакой поток не освободился, то создается новый поток, а значение интервала увеличивается еще на две секунды, и т.д...
Понял. Это — первоначальный вариант.
R>>В этой ситуации, при условии, что операции *не* блокирующие, как раз бы уменьшать кол-во потоков, что бы повысить пропускную способность. А тут получается, что с повышением нагрузки, фреймворк начинает только увеличивать накладные расходы на переключения контекстов и потребление ресурсов (память под потоки), тем самым только усугубляя ситуацию... С>С этим согласен. Только как определить, что текщий обработчик сообщения вызвал блокирующую операцию? Если есть такая возможность, то конечно, так будет правильно, а иначе приходится действовать эвристическими методами.
Хороший вопрос. Похоже, что под Win32 красиво и точно это сделать нельзя. Только если применять какие-то хаки, драйвера и т.д.
С>А вообще, смысл библиотеки acto в том, чтобы предоставить удобный асинхронный интерфейс, имея который можно было бы не использовать блокирующие операции.
Я бы даже пошёл дальше, и запретил бы вообще использовать блокирующие операции. Ну точнее отвести под них отдельный пул потоков и помечать сообщения, которые могут вызвать блокировку при обработке, каким-либо способом.
Здравствуйте, Стэн, Вы писали:
С>Здравствуйте, remark, Вы писали:
R>>А на какую производительность ты нацеливаешься?
С>Ну, а какой русский не любит быстрой езды?..
Хороший ответ
С>А если конкретно, то я не очень понял вопрос, поэтому отвечу как понял.
Вопрос был в том, имеет ли смысл мне излагать свои параноидальные соображения, нацеленные на параноидально экстремальную производительность?
С>Есть вычислительная модель — легкие процессы, которые могут обрабатывать задания (tasks). Отдельно взятый процесс обрабатывает свои задания строго последовательно. Два произвольно взятых процесса обрабатывают свои собственные задания независимо друг от друга, и в общем случае могут делать это параллельно. Такова вычислительная модель. Очень возможно, что есть класс задач, для которых такая модель не очень подходит, так как непроизводительные издержки (создание и пересылка task'ов) могут оказаться пропорциональны или даже превышать полезную нагрузку. Очевидно, что для таких задач необходимо выбирать другую вычислительную модель, и, соответственно, необходимо выбрать какую-то другую библиотеку.
В идеале, конечно, под каждую задачу выбирается соотв. средство.
На практике разработчик обычно пользуется одним средством всегда
В этом, по моему мнению, принципиальный просчёт всех ныне существующих библиотек поддержки параллельных вычислений. Такие вещи как OpenMP, Intel TBB, Cilk, Java ForkJoin являются максимально эффективными, но рассчитаны исключительно на HPC, кодировать какую-либо логику на них не представляется возможным. Такие вещи как SObjectizer рассчитаны исключительно на бизнес-логику/сервера, но низкоэффективны, поэтому кодировать с их помощью какие-либо эффективные параллельные алгоритмы не представляется возможным.
Вопрос как спозиционирует себя act_0?
Здравствуйте, Стэн, Вы писали:
С>Здравствуйте, Edge, Вы писали:
E>>А будет ли поддержка NUMA? Правда у меня нет сейчас доступа к Opteron машине, чтоб посмотреть и погонять... С>Да. С самого начала я ставил себе целью сделать такую библиотеку, которая, предоставляя высокоуровневые абстракции, позволяла бы не думать о потоках, о синхронизациях, о количестве процессоров, но задействовать ресурсы компьютера по-максимуму. NUMA позволяет каждому процессору быстрее обмениваться с памятью, если она для него локальная. Для некоторого класса приложений это может оказаться важным и обойти стороной подобную возможность ускорить их было бы неправильно. Однако пока рано говорить о том, как это будет выглядеть и какие дополнительные абстракции будут предоставлены для поддержки NUMA.
Имхо для поддержки NUMA тебе придётся отказаться от идеи иметь произвольное кол-во потоков, произвольно мигрировать потоки с процессора на процессор, и самое главное от идеи, что весь load-balancing за тебя будет делать ОС. При реализации всего этого скорее всего придётся переработать не только весь ран-тайм, но и, возможно, интерфейс...
Здравствуйте, Стэн, Вы писали:
С>Здравствуйте, remark, Вы писали:
R>>Например, в твоём примере ping-pong проблемы может вызвать актёр Wall. Через него проходит каждое второе сообщение, и он сериализует всю обработку. Допустим на системе с 16 аппаратными потоками, актёры Player могут обрабатываться параллельно и масштабируемо. Но актёр Wall будет обрабатываться только в одном потоке в каждый момент времени. Т.е. производительность системы ограничена скоростью, с которой *один* поток сможет обрабатывать сообщения актёра Wall. Система не масштабируется.
R>>Некоторые варианты решения: R>> — разрешить обрабатывать сообщения для Wall на разных потоках одновременно R>> — "партицировать" актёра Wall на много "частей" по кол-ву аппаратных потоков, сообщения для каждой "части" актёра могут обрабатываться параллельно
R>>Что думаешь? С>Я думаю, что вычислительную модель лучше не трогать. Она проста, понятна и от нее можно ожидать того, что в каждый момент времени, каждый актер может обрабатывать только одно сообщение. Нарушим этот принцип, и я более чем уверен, что очень быстро возникнет ситуация когда — "да, девять полей в объекте могут безопасно обрабатываться в разных потоках, но вот десятое, его бы немножечко мьютексом..." С>С самого начала я ставил себе цель уйти от подобных мьютексов, так что я однозначно за второй вариант.
В такой схеме не получится эффективно реализовывать алгоритмы типа fork/join (divide and conquer, параллельный вариант рекурсии), когда актёр при обработке сообщения отправляет себе ещё 2 (или в общем случае N) таких же сообщений (но с меньшим объёмом данных). Основная идея, что эти дочерние сообщения как раз и должны распараллеливаться. В твоей схеме придётся для каждого дочернего сообщения создавать так же и нового актёра, что бы он обработал единственное сообщение. А создание актёра скорее всего получится на порядок тяжелее создания сообщения.
Здравствуйте, remark, Вы писали:
R>Имхо для поддержки NUMA тебе придётся отказаться от идеи иметь произвольное кол-во потоков, произвольно мигрировать потоки с процессора на процессор, и самое главное от идеи, что весь load-balancing за тебя будет делать ОС. При реализации всего этого скорее всего придётся переработать не только весь ран-тайм, но и, возможно, интерфейс...
Да, очень может быть, что придется... Но так как на текущей версии я останавливаться не планирую, то это меня не слишком пугает.
Просто при выпуске измененного интерфейса я планирую некоторое время поддерживать старый интерфейс и обновлять для него runtime, если это кому-нибудь будет необходимо.
Re[7]: [ann] act-o – библиотека асинхронного программировани
Здравствуйте, remark, Вы писали:
С>>Я думаю, что вычислительную модель лучше не трогать. Она проста, понятна и от нее можно ожидать того, что в каждый момент времени, каждый актер может обрабатывать только одно сообщение. Нарушим этот принцип, и я более чем уверен, что очень быстро возникнет ситуация когда — "да, девять полей в объекте могут безопасно обрабатываться в разных потоках, но вот десятое, его бы немножечко мьютексом..." С>>С самого начала я ставил себе цель уйти от подобных мьютексов, так что я однозначно за второй вариант.
R>В такой схеме не получится эффективно реализовывать алгоритмы типа fork/join (divide and conquer, параллельный вариант рекурсии), когда актёр при обработке сообщения отправляет себе ещё 2 (или в общем случае N) таких же сообщений (но с меньшим объёмом данных). Основная идея, что эти дочерние сообщения как раз и должны распараллеливаться. В твоей схеме придётся для каждого дочернего сообщения создавать так же и нового актёра, что бы он обработал единственное сообщение. А создание актёра скорее всего получится на порядок тяжелее создания сообщения.
Конечно, если так прямолинейно пытаться реализовать все алгоритмы, то придется создавать дополнительные актеры, однако я с самого начала понимал, что это не Smalltalk... И мои актеры нужны для взаимодействия активностей, а не для построения произвольного алгоритма на основе обмена сообщениями. Скажем, тот же fork/join можно реализовать не отказываясь от модели актеров, просто один актер будет представлять полноценный вычислитель, а как он там будет распараллеливать задания — это отдельный вопрос...
Re[8]: [ann] act-o – библиотека асинхронного программировани
С>Конечно, если так прямолинейно пытаться реализовать все алгоритмы, то придется создавать дополнительные актеры, однако я с самого начала понимал, что это не Smalltalk... И мои актеры нужны для взаимодействия активностей, а не для построения произвольного алгоритма на основе обмена сообщениями. Скажем, тот же fork/join можно реализовать не отказываясь от модели актеров, просто один актер будет представлять полноценный вычислитель, а как он там будет распараллеливать задания — это отдельный вопрос...
Вопрос именно про ситуацию, когда я (пользователь библиотеки) хочу реализовать алгоритм по модели fork/join. Тут меня не устраивает ситуация "а как он там будет распараллеливать задания — это отдельный вопрос".
Здравствуйте, remark, Вы писали:
R>Здравствуйте, Стэн, Вы писали:
С>>Конечно, если так прямолинейно пытаться реализовать все алгоритмы, то придется создавать дополнительные актеры, однако я с самого начала понимал, что это не Smalltalk... И мои актеры нужны для взаимодействия активностей, а не для построения произвольного алгоритма на основе обмена сообщениями. Скажем, тот же fork/join можно реализовать не отказываясь от модели актеров, просто один актер будет представлять полноценный вычислитель, а как он там будет распараллеливать задания — это отдельный вопрос...
R>Вопрос именно про ситуацию, когда я (пользователь библиотеки) хочу реализовать алгоритм по модели fork/join. Тут меня не устраивает ситуация "а как он там будет распараллеливать задания — это отдельный вопрос".
Да я понял вопрос. Еще раз. Есть два уровня, которые необходимо четко разделять. 1) Среда выполнения (runtime) 2) Интерфейс.
Я экспериментировал с фьючерсами (асинхронными процедурами), с помощью которых можно реализовать fork/join с минимальным оверхедом. Это был совершенно другой интерфейс нежели модель актеров, но алгоритмы runtime'а почти один в один.
Поэтому, возвращаясь на пару вопросов назад, чтобы реализовать модель fork/join совершенно ненужно позволять актерам обрабатывать по нескольку сообщений одновременно, но необходим специальный интерфейс для этого, которого, конкретно в библиотеки acto, на данный момент — нет. Но важно, что эти два интерфейса могли бы работать на одном runtime.
Re: [ann] act-o – библиотека асинхронного программирования
Здравствуйте, IROV.., Вы писали:
IRO>Вот сейчас есть желание прикрутить эту библиотеку.
Спасибо за проявленный интерес, постараюсь вам в этом помочь.
IRO>Сразу возник вопрос, как можно прикрутить ping-pong с main thread? IRO>в примерах показано как можно общатся между разными потоками, а как быть с главным потоком?
Для этого придется кое-что дописать, только необходимо уточнить как именно? У вас есть свой цикл в главном потоке, из которого вы хотите выбирать сообщения ему адресованные, или какая-то другая схема?
IRO>и еще что будет если главный поток в данный момент "завис" на 1 минуту?
Если этот вопрос задан с учетом реализации первого абзаца, то пока не известно, а если "что будет с остальными потоками, если главный завис (в текущей реализации)", — то ничего, будут работать автономно.
IRO> существует ли очередь команд?
Такого понятия на пользовательском уровне на данный момент не существует, но если вы поясните, что вы под этим понимаете, то я буду благодарен. Особенно интересно — команд кому (чему)?
Re[3]: [ann] act-o – библиотека асинхронного программировани
Здравствуйте, Стэн, Вы писали:
С>Здравствуйте, IROV.., Вы писали:
IRO>>Сразу возник вопрос, как можно прикрутить ping-pong с main thread? IRO>>в примерах показано как можно общатся между разными потоками, а как быть с главным потоком? С>Для этого придется кое-что дописать, только необходимо уточнить как именно? У вас есть свой цикл в главном потоке, из которого вы хотите выбирать сообщения ему адресованные, или какая-то другая схема?
ну например хочу создать acto обьект который гарантируемо будет процесится в главном потоке
IRO>>и еще что будет если главный поток в данный момент "завис" на 1 минуту? С>Если этот вопрос задан с учетом реализации первого абзаца, то пока не известно, а если "что будет с остальными потоками, если главный завис (в текущей реализации)", — то ничего, будут работать автономно.
Я посылаю сообщение от другого обьекта раз в 10 милисекунд (читаю буфер из сокета) а в это время в главном цыкле произошол лаг на 100 милисекунд. Получается я отослал 10 сообщений, что произойдет с ними?
я не волшебник, я только учусь!
Re[4]: [ann] act-o – библиотека асинхронного программировани
Здравствуйте, IROV.., Вы писали:
IRO>ну например хочу создать acto обьект который гарантируемо будет процесится в главном потоке
Понятно. Я эксперементировал с такой возможностью, но в текущей версии этого действительно нет. В ближайшие пару дней посмотрю, как это можно красиво в писать в существующий интерфейс.
IRO>Я посылаю сообщение от другого обьекта раз в 10 милисекунд (читаю буфер из сокета) а в это время в главном цыкле произошол лаг на 100 милисекунд. Получается я отослал 10 сообщений, что произойдет с ними?
Сообщения ставятся в очередь и никуда не исчезают. Они будут обработаны по окончанию лага.
Re[5]: [ann] act-o – библиотека асинхронного программировани
Здравствуйте, Стэн, Вы писали:
С>Здравствуйте, IROV.., Вы писали:
IRO>>ну например хочу создать acto обьект который гарантируемо будет процесится в главном потоке С>Понятно. Я эксперементировал с такой возможностью, но в текущей версии этого действительно нет. В ближайшие пару дней посмотрю, как это можно красиво в писать в существующий интерфейс.
Ждемс
IRO>>Я посылаю сообщение от другого обьекта раз в 10 милисекунд (читаю буфер из сокета) а в это время в главном цыкле произошол лаг на 100 милисекунд. Получается я отослал 10 сообщений, что произойдет с ними? С>Сообщения ставятся в очередь и никуда не исчезают. Они будут обработаны по окончанию лага.
Ок, спасибо!
я не волшебник, я только учусь!
Re: [ann] act-o – библиотека асинхронного программирования
Хочу еще посоветовать сделать, если есть такая возможность.
Collocation Optimization — в двух словах, если обьекты которые отсылают сообщения, вдруг находятся в одном треде, посылались в обход очереди и синхронизации.
Потом было бы очень интересно видеть async запросы с response на них.
Здравствуйте, IROV.., Вы писали:
IRO>Collocation Optimization — в двух словах, если обьекты которые отсылают сообщения, вдруг находятся в одном треде, посылались в обход очереди и синхронизации.
Идея хорошая, т.к. может существенно ускорить обработку, т.к. в некоторых сценариях имеется существенный процент "локальных" сообщений. Только при реализации надо учитывать следующий момент.
Сообщения, идущие в обход очереди, и сообщения, идущие через очередь, всё ещё должны составлять гарантированный casual-fifo порядок. Тут надо немного подумать, т.к. нельзя обрабатывать вначале все сообщения из очереди, и потом все сообщения в обход очереди. И нельзя наоборот. Их надо неким образом перемеживать.
Если используются lock-based очереди, то я не уверен, что удасться получить какую-то выгоду от "Collocation Optimization", т.к. для обеспечения "промеживания" сообщений всё равно придётся захватывать lock очереди. При использовании lock-free очереди "промеживание" можно организовать достаточно эффективно.
Мне кажется именно в таком виде не получится сделать, т.к. сообщения типизированные. Соотв. не понятно что делать, если функция fooResponse принимает msg1_t, а функция foo_async отсылает в ответ msg2_t. Хотя, бесспорно, встроенная поддержка паттерна "запрос-ответ" очень приятна.
Здравствуйте, remark, Вы писали:
R>Мне кажется именно в таком виде не получится сделать, т.к. сообщения типизированные. Соотв. не понятно что делать, если функция fooResponse принимает msg1_t, а функция foo_async отсылает в ответ msg2_t. Хотя, бесспорно, встроенная поддержка паттерна "запрос-ответ" очень приятна.
R>
Именно в таком виде, мы организовали, получается очень и очень удобно и быстро писать асинхронный код. Вправде мы юзаем ICE как сетевое решение, сейчас на клиенте понадобилась асинхроная библиотечка, вот и хочется помочь развить данный проект.
правда я не знаю получится ли это сделать без какой либо кодогенерации, но есть ощушение что можно.
на досуге попробую сделать прототип
я не волшебник, я только учусь!
Re[4]: [ann] act-o – библиотека асинхронного программировани
Здравствуйте, IROV.., Вы писали:
R>>Мне кажется именно в таком виде не получится сделать, т.к. сообщения типизированные. Соотв. не понятно что делать, если функция fooResponse принимает msg1_t, а функция foo_async отсылает в ответ msg2_t. Хотя, бесспорно, встроенная поддержка паттерна "запрос-ответ" очень приятна.
IRO>Именно в таком виде, мы организовали, получается очень и очень удобно и быстро писать асинхронный код. Вправде мы юзаем ICE как сетевое решение, сейчас на клиенте понадобилась асинхроная библиотечка, вот и хочется помочь развить данный проект.
Я не говорю, что это вообще не возможно. Я только сказал, что это не возможно в таком виде, в таком контексте. В таком контексте надо делать в каком-то другом виде.
Здравствуйте, alzt, Вы писали:
A>Здравствуйте, Стэн, Вы писали: A>Из ваших исходников (act_config.h):
Спасибо, что обратили внимание, действительно должно быть по другому.
Признаюсь, что это сделано как заглушка, и в той версии не проверялось, что все будет правильно собираться и работать в виде dll-библиотеки.
Re[6]: [ann] act-o – библиотека асинхронного программировани
Здравствуйте, IROV.., Вы писали:
IRO>>>ну например хочу создать acto обьект который гарантируемо будет процесится в главном потоке С>>Понятно. Я эксперементировал с такой возможностью, но в текущей версии этого действительно нет. В ближайшие пару дней посмотрю, как это можно красиво в писать в существующий интерфейс. IRO>Ждемс
Готов первый прототип. Пока чтобы пощупать, так как он еще не стабильный. Брать можно из svn, как именно читать здесь.
Нововведения следующие:
1. Добавился новый флаг acto::aoBindToThread. Работает только из потоков созданных пользователем самостоятельно, т.е. бесполезно вызывать внутри других объектов:
А каким образом можно проделать следующее:
Есть статическая функция. Необходимо сделать длинное действие. Функция должна подождать окончания этого действия (2 варианта — а. выполняя при этом некоторую свою работу, б. ничего не делая в этот момент, желательно не тратить ресурсы), после чего завершить работу.
?
Варианты с _getch() как-то не очень нравятся.
Re[2]: [ann] act-o – библиотека асинхронного программировани
Здравствуйте, alzt, Вы писали:
A>Здравствуйте, Стэн, Вы писали:
A>А каким образом можно проделать следующее: A>Есть статическая функция. Необходимо сделать длинное действие. Функция должна подождать окончания этого действия (2 варианта — а. выполняя при этом некоторую свою работу, б. ничего не делая в этот момент, желательно не тратить ресурсы), после чего завершить работу. A>?
A>Варианты с _getch() как-то не очень нравятся.
Если вы имеете ввиду (как вариант) задачу о том, как дождаться завершения работы acto-объекта из основного потока, то это будет решено вместе с задачей обсуждаемой сейчас параллельно в этой теме (обработка сообщений из основного потока).
Это недостаток вышеописанной схемы. Сейчас я активно работаю, чтобы улучшить ее. Но даже в текущей схеме много потоков насоздается только, если сообщения будут посылаться непрерывно с очень большой интенсивностью.
