SObjectizer 5.3.0

Цитата eao197 @ 13.04.15, 11:51

На SObjectizer не точь-в-точь такие задачи решались

Вот это вот

Цитата

Программа представляет собой многопоточное приложение, с архитектурой: мастер + один или несколько воркеров.
Количество воркеров определяется на старте программы, и, обычно, равно количеству вычислительных ядер в машине.
Мастер вычитывает задания из stdin построчно и раздаёт их свободным воркерам. Пустые строки могут игнорироваться сразу и не восприниматься как задания. Чтение должно либо чередоваться с обработкой, либо вестись параллельно. Нельзя однократно прочитать содержимое stdin от начала до конца и лишь затем приступить к обработке прочитанного (т.к. программа должна иметь возможность работать в составе, например, конвейера в течении длительного периода и обрабатывать миллионы/сотни миллионов/миллиарды строк с stdin).
Задание -- это md5-сумма пароля и диапазон возможных значений пароля. И нижняя, и верхняя граница интервала входит в поиск (т.е. диапазон вида [lower,upper]).
Символы пароля и интервалов могут быть либо цифрами, либо строчными латинскими буквами.
Пример строки с заданием: fec91335051486b245d74cdb6042d4c0 0ayie zayie
Воркер получает задание, пытается подобрать значение из указанного в таске диапазона, которое даст такой же md5-хеш. Такое значение может быть, а может и не быть. О результате воркер сообщает мастеру, который печатает отчёт на stdout.
Получение результата мастером означает, что воркер освободился и может получить следующий таск (если таковые еще есть).
Диапазоны могут быть заданы некорректно.
zzz 000 -- нарушение правила lower меньше upper.
0000 zz -- в upper меньше символов, чем в lower.
aaaa aaAz -- символ A не входит в разрешенный алфавит
Помимо некорректных диапазонов, ошибка может возникать при парсинге строки, и некорректном формате md5-суммы.
Столкнувшись с ошибкой, воркер должен "упасть" (завершить работу).
Эту ситуацию должен отловить мастер и запустить вместо упавшего воркера нового. Проблемное задание при этом выбрасывается, но на stderr должен быть отчёт от мастера.
Если воркер завершил обработку задачи без ошибок, то этот воркер должен быть переиспользован для одного из следующих заданий (если таковые будут). Т.е. допускается создание воркеров по мере необходимости, но не допускается создание/пересоздание воркеров для каждого нового задания.
Завершение работы программы происходит при достижении конца stdin и завершении обработки всех начатых заданий.

не задача. Это пояснения для младшего программиста как надо сделать.

Сообщение отредактировано: MyNameIsIgor - 14.04.15, 16:35

Цитата MyNameIsIgor @ 14.04.15, 16:35

Это пояснения для младшего программиста как надо сделать.

Как оказалось, даже такого подробного объяснения не хватает, чтобы сделали именно то, что требуется.

В обсуждениях релизов SO-5 зачастую говорят о том, что сделано все сложно, коряво, непонятно, неправильно и т.д. Допустим, есть возможность все сделать с чистого листа, с нуля, сразу правильно и понятно. Как это должно выглядеть?

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

Как-то в обсуждении SO-5 всплыла тема приоритетов сообщений. Мол, приоритеты нужны, без них плохо. В находящейся сейчас в разработке версии 5.5.5 есть возможность добавить поддержку оных. Что к чему, описано на SF.net и на GitHub-е. Если найдутся заинтересовавшиеся, то обсудить можно будет либо там, либо непосредственно здесь.

Выпущена версия 5.5.5.

Ее можно взять либо из секции Files на SF, либо из Svn-репозитория, либо из зеркала на GitHub.

Если говорить кратко, то в версии 5.5.5 появилось следующее:

• вспомогательные шаблонные методы introduce_coop и introduce_child_coop, упрощающие создание и регистрацию коопераций;
  
• возможность использования туплов в качестве типов сообщений;
  
• фильтры для сообщений, которые позволяют анализировать содержимое сообщений и отбрасывать те из них, которые не интересны агенту получателю;
  
• несколько новых примеров.

Так же подготовлены две новые части серии презентаций “Dive into SObjectizer-5.5”, более подробно рассказывающие о состояниях агентов и кооперациях агентов (все имеющиеся презентации собраны здесь).

Если интересны подробности, то сюда.

Отдельная благодарность Алексею Сырникову, как за помощь в подготовке этого релиза, так и за поддержку зеркала SObjectizer на GitHub-е.

Сообщение отредактировано: eao197 - 27.05.15, 10:03

Цитата bsivko @ 01.07.14, 12:41

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

Можно глянуть на какой-нибудь проект, использующий сабж, но более практичный чем "пинг-понг" или "хелоуворлд"?

Цитата JoeUser @ 27.05.15, 06:30

Можно глянуть на какой-нибудь проект, использующий сабж, но более практичный чем "пинг-понг" или "хелоуворлд"?

Открытых проектов на SO-5, насколько я знаю, сейчас нет.

SO-5 продолжает активно использоваться в "Интервэйл", где он и появился впервые, но там все разработки закрытые, насколько мне известно.

Добавлено 27.05.15, 07:08

Цитата JoeUser @ 27.05.15, 06:30

Можно глянуть на какой-нибудь проект, использующий сабж, но более практичный чем "пинг-понг" или "хелоуворлд"?

Некоторое время назад я специально поднимал вопрос о демо-проекте, который был бы интересен не только разработчикам SO-5. Но что-то никаких интересных идей никто не озвучил, а так как в самом SO-5 было еще много работы, то эта тема не взлетела.

Однако, данное предложение все еще открыто, т.ч. если есть какие-то идеи, то можно их рассмотреть и сделать какой-то приближенный к реальности демо-проект.

Цитата eao197 @ 27.05.15, 06:33

Однако, данное предложение все еще открыто

Навскидку два предложения:

1) Распределенная версия 7z

Возможно на ее основе - система резервного копирования. Если я не ошибаюсь, использование алгоритма LZMA2 позволяет распараллеливать процесс. Есть еще идея - использовать LZMA (т.к. он может позволять большую степень сжатия нежели LZMA2), но процесс строить несколько по другому - многоходовкой. В первом проходе строятся "локальные" словари, во втором проходе строится/вычисляется объединенный словарь, в третьем проходе собственно процесс сжатия на основе объединенного словаря.

Возможны эксперименты и с другими типами алгоритмов сжатия, типа PPMD, ZPAQ

2) Процесс видеокодирования

Тут, увы, я пасс - не знаю особенностей и возможностей распараллеливания - интересует кодек x264. Возможно, нет - без понятия. Хотя в опциях двухпроходной режим есть. А возможно ли "порционное" сжатие - я без понятия.

Добавлено 27.05.15, 07:53
По первому предложению ... было бы здорово иметь систему архивации со скоростью отдачи информации равной производительности дисковой подсистемы и максимальной степенью сжатия. Это вообще сказка для больших контор, имхо.

Сообщение отредактировано: JoeUser - 27.05.15, 07:53

Цитата JoeUser @ 27.05.15, 07:48

Навскидку два предложения:

1) Распределенная версия 7z

2) Процесс видеокодирования

Спасибо! Есть над чем подумать... Хотя для распараллеливания обработки видео, скорее всего, IBB или HPX, а может даже и OpenMP, будут более подходящими инструментами.

Тут вспомнилось несколько простых примеров, которые, с одной стороны, посложнее hello_world-а, а с другой более-менее приближены к реальности (в обратном хронологическом порядке):

Чуть подробне про решение md5_bruteforce2 на SObjectizer
Многопоточность и Pub-Sub с помощью SObjectizer
На пути к 50M msg/sec... (Akka нам не страшна?)
Разбор примера простой реализации дедлайнов для сообщений
Пример решения проблемы Producer-Consumer в SO-5.5.1
Асинхронность без порталов и телепортации

Цитата eao197 @ 27.05.15, 08:00

Хотя для распараллеливания обработки видео, скорее всего, IBB или HPX, а может даже и OpenMP, будут более подходящими инструментами.

Если посмотреть с другой стороны, сжатие компрессорами и обработка видео - одного поля ягоды. Обработка входящего потока + получение сжатого. Просто на выходе разного качества инфа. В первом случае строго loseless, во втором - желательно. Одно только разнит их. Для архивов не принципиальна скорость разархивирования, для видеоматериала скорость "извлечения" кадров принципиальна.

Одна из важнейших тем при работе с SO5 -- это использование исключений. Долго не удавалось выкроить время и подготовить более-менее подробный рассказ на эту тему. Сейчас удалось. Очередную часть серии Dive into SObjectizer-5.5, полностью посвященную исключениям, можно найти здесь (или на SlideShare).

В одном из обсуждений SO-5 подкинули идею о том, а нельзя ли декларативно описывать цепочки обработки сообщений таким образом, чтобы все необходимые агенты и связи между ними создавались автоматически. Да еще и с контролем со стороны компилятора за соответствием типов сообщений и их обработчиков.

Оказалось, что можно. Получается что-то вроде:

virtual void so_evt_start() override
{
    // Создание конвейера.
    // Возвращается mbox самой первой стадии созданного конвейера.
    // Отсылая сообщения на этот mbox инициируется цепочка событий
    // по обработке отосланного сообщения.
    auto pipeline = make_pipeline( *this,
            src | stage(validation) | stage(conversion) | broadcast(
                src | stage(archivation),
                src | stage(distribution),
                src | stage(range_checking) | stage(alarm_detector{}) | broadcast(
                    src | stage(alarm_initiator),
                    src | stage( []( const alarm_detected & v ) {
                            alarm_distribution( cerr, v );
                        } )
                    )
                ),
            autoname );
 
    send_delayed_to_agent< shutdown >( *this, chrono::seconds(1) );
 
    // Использование конвейера.
    // Посредством отложенных сообщений имитируется поступление
    // данных от датчика температуры.
    for( uint8_t i = 0; i < static_cast< uint8_t >(250); i += 10 )
        send_delayed< raw_value >(
                so_environment(),
                pipeline,
                chrono::milliseconds( i ),
                raw_measure{ 0, 0, i } );
}

Более подробное описание можно найти здесь. Собственно, сейчас самый большой вопрос такой: имеет смысл продолжать эти эксперименты? Или можно зафиксировать то, что получилось и пойти дальше.

В следующей версии 5.6 планируется нарушить совместимость с версией 5.5. Что дает возможность упростить какие-то вещи в использовании SObjectizer. Например, отказаться от использования so_define_agent().

Иногда говорят, что в SObjectizer "сложно врубиться". Можно упростить. И не только это. Нужно только определить, что вызывает сложности и недопонимание.

Вышла версия 5.5.8.

Версию 5.5.8 можно взять либо из секции Files на SF, либо из Svn-репозитория, либо из зеркала на GitHub.

Если говорить кратко, то в версии 5.5.8 появилось следующее:

• приоритеты у агентов и три новых диспетчера, которые выполняют обработку событий с учетом приоритетов;
  
• более удобные средства работы с ad-hoc агентами;
  
• несколько новых примеров.

Если интересны подробности, то сюда, либо сюда, либо сюда.

Краткую информацию о том, что такое SObjectizer можно найти здесь и далее по ссылкам.

Мы подготовили рассказ о работе с таймерами (т.е. об использовании отложенных и периодических сообщений) в виде небольшой презентации (копия на slideshare).