пятница, 14 февраля 2014 г.

Asio samples were moved to GitHub

Для читателей блога и нелюбителей SourceForge (есть за что) перепечатываю эту запоздалую "новость":

Asio samples were moved to GitHub.
The SourceForge SVN repository and files won't get updates anymore.
There won't be any other announces in asio-samples mailing list, however I'll continue to answer questions posted there.
The preferred way for bug reporting is GitHub issues page.

суббота, 7 сентября 2013 г.

await добрался до C++

Смотрю GoingNative 2013.

Особенно интересно выступление по теме "Bringing await to C++". "Асинронность" (ожидаемо) идет в массы и становится трендом. Настолько, что ее поддержку внедряют в компилятор и в будущий стандарт C++ (надеюсь, что последнее все-таки свершится). Понятное дело, это все для того, чтобы сделать программирование "асинхронности" максимально удобным для обывателей "среднестатистического программиста" и лучше оптимизировать.

Stackfull coroutines (наконец-то) идут в массы. Всего какой-то год назад "текли слюни" при взгляде на поддержку await в C#! Видимо, компании, которые массово используют C++ и потому влияют на его развитие, действительно активно используют асинхронные алгоритмы и остро нуждаются в средствах, способных облегчить их реализацию на C++ (а заодно и лучше оптимизировать подобный код).

Кто еще сомневается в необходимости работать с вводом-выводом асинхронно даже в клиентской части (например, уеt another messenger)? На "рельсы асинхронности" уже планируют перевести не только сетевой ввод-вывод - смотрите, примеры-то у всех (кто говорит, про PPL, std::future::then и даже про уже существующий WinRT) работают со "старыми добрыми" файлами (а, может быть, просто у них пока нет чего-то более-менее стандартного и краткого для сетевого ввода вывода?). И не только (правда, там уже делают больший упор на lazy-вычисления).

P.S. Q&A Panel особенно порадовала. Определенно, нынешний GoingNative гораздо лучше предыдущего и лучше уже прошедшего C++Now. Отличные докладчики (хотя их состав почти не меняется) с неплохим чувством юмора!

воскресенье, 1 сентября 2013 г.

::boost::asio::io_service::strand и лишние проверки

Среди заголовочных файлов "asio samples" лежит "скромный" ma/strand_wrapped_handler.hpp. Когда-то, разбираясь с invocation strategy и io_service::strand, я наткнулся на то, что стандартно обернутый через asio::io_service::strand::wrap() функциональный объект делает проверку (на исполнение в контексте strand-а) и в asio_handler_invoke, и в своем operator(). Так вот, обычно достаточно делать такую проверку только в asio_handler_invoke. "Обычно" в этом предложении означает: для всех классов Boost.Asio и вообще везде, где вы сами не вызываете напрямую operator() у функционального объекта, "обернутого" через strand. В противном случае, при использовании asio_handler_invoke с таким образом обернутым функциональным объектом (вспоминаем, что Boost.Asio всегда вызывает все user-defined обработчики только так), проверка на исполнение в контексте strand будет выполняться дважды! Данная операция не такая уж и легкая (использует мютексы/критические секции). Кому интересно, загляните в исходники Asio.

С тех пор (давно) вместо asio::io_service::strand::wrap() везде в "asio samples" я использую свой макрос MA_STRAND_WRAP(strand, handler), определенный в том самом ma/strand_wrapped_handler.hpp. Моя strand-"обертка" для функционального объекта использует asio::io_service::strand::dispatch только в asio_handler_invoke.

Автору Asio я писал (давно, в список рассылки). Он ответил, что те, кого волнуют подобные двойные проверки (я согласен с тем, что еще не известно, как/насколько они скажутся на производительности) смогут аналогично мне сами написать свою обертку. Кхм... В свете того, что Asio все чаще используется даже высоконагруженными гигантами вроде Mail.ru (и, кажется, уже давно в Yandex), хотел бы порекомендовать пользователям Asio по-чаще смотреть в исходники самой библиотеки Asio.

среда, 31 июля 2013 г.

Ожидаемая C++ IDE от создателей замечательной IntelliJ IDEA

Давно ждал новостей о C++ IDE от гениальных JetBrains. Сожалел, что не смог попасть на день открытых дверей JetBrains. А недавно наткнулся в RSS Хабра на "Видео с дня открытых дверей JetBrains", где есть видео презентации "C++ IDE и как с ней бороться":



Чтож, c нетерпением жду ReSharper с поддержкой C++ и саму С++ IDE. Жизнь в мире C++ становится все более комфортной и все менее олдскульной (Far Manager + Colorer Plugin!?).

Asio samples 0.6.0 is out

Вышла очередная бета asio samples 0.6.0. Приведу здесь только основные изменения:
  • Класс ma::console_controller переименован в ma::console_close_guard и реализован через boost::asio::signal_set для *nix и через ma::windows::console_signal (см. ниже) для Windows.
  • Представлен класс (расширение Boost.Asio) ma::windows::console_signal (+ ma::windows::console_signal_service). Данный класс может использоваться как каркас для расширений Boost.Asio, использующих внутренние потоки. Он будет подробнее освещен в отдельной статье позже. Пока же скажу лишь, что класс ma::windows::console_signal (определен только при сборке для Windows 2000 и выше) позволяет асинхронно ожидать сигнала к закрытию консольного приложения пользователем (путем использования комбинации клавиш Ctrl+C/Ctrl+Break, закрытия окна или выхода из системы/завершения работы компьютера)
  • Выделены отдельно и изменены классы ma::detail::intrusive_list и ma::detail::intrusive_slist: добавлены ссылки на конец списка, которые позволили реализовать конкатенацию списков со сложностью O(1).
  • Добавлена поддержка Qt 5, Boost C++ Libraries 1.53/1.54.

Остальные детали беты 0.6.0 можно прочитать в списке рассылки.

Updated
Исправление ошибок в классах ma::console_close_guard и ma::windows::console_signal_service вылилось в asio samples 0.6.1.

понедельник, 29 октября 2012 г.

Asio samples 0.5.0 is out

Вышла очередная бета asio samples 0.5.0. Приведу здесь основные изменения, которых хватило аж на смену среднего номера версии.

Во-первых, сильно изменился (в лучшую сторону) класс ma::handler_storage. Теперь он поддерживает функциональные объекты с operator()(void) при специализации ma::handler_storage<void>.

Кроме того, наконец-то, метод ma::handler_storage::target() стал типизированным, что избавляет его пользователей (см. проект nmea_client) от неприятных reinterpret_cast. По умолчанию ma::handler_storage::target() возвращает void*, но теперь, при желании, этот тип можно специфицировать указав его в качестве второго шаблонного аргумента ma::handler_storage.

При такой специализации для класса ma::handler_storage_service должно быть доступно преобразование static_cast<Target*>(Handler*), где
  • Target - специфицированный для ma::handler_storage::target() тип (т.е. Target* ma::handler_storage<Arg, Target>::target()).
  • Handler - тип функционального объекта, хранимого в ma::handler_storage.

Второе крупное нововведение заключается в поддержке проектами qt_echo_server, echo_server, async_connect и asio_performance_test_client режима io_service-per-work-thread (по аналогии с HTTP Server 2 из примеров Asio). Для CLI за этот режим отвечает параметр demux_per_work_thread. Для Windows режим io_service-per-work-thread по умолчанию отлючен (--demux_per_work_thread=0, false, off). Для других платформ - по умолчанию включен (--demux_per_work_thread=1, true, on).

Остальные детали беты 0.5.0 можно прочитать в списке рассылки.

Updated
Исправление ошибок и расширение поддержки лямбд вылилось в asio samples 0.5.1.

четверг, 19 июля 2012 г.

asio performance test

Данное сообщение будет служить для сбора всей информации, что мне удастся собрать по теме производительности Asio. Буду рад видеть в комментариях вопросы/критику/дополнения и результаты/методики тестов читателей.

Для начала выложу самое простое – отчеты профилировщика MS VS 2010. И клиент и сервер работали одновременно на моей домашней машине (причем без отключения прочих приложений вроде uTorrent и MS Outlook):
  • MS Windows 7 Pro x64 SP1 + все обновления на 19.07.2012
  • ASUS P6T Deluxe (LGA 1366)
  • Intel Core i7 920 2.6Hz (4 physical cores), Hyper-threading on (8 logical cores)
  • 12 Gb RAM 1333MHz
  • Boost C++ Libraries 1.50 + все патчи из /asio_samples/build/patches/boost_1_50_0
  • Qt 4.8.2 static build with static C/C++ runtime + патчи из /asio_samples/build/patches/qt_4_8_1_patches: build_static_win32-msvc2010.patch, container_msvc_warn.patch, win_cursors.patch
  • Исходники asio samples из https://asio-samples.svn.sourceforge.net/svnroot/asio-samples/trunk (revision 617)
  • Проект echo_server, собранный в конфигурации Profile/Win32
  • Проект asio_performance_test_client, собранный в конфигурации Profile/Win32

Тестирование echo_server (echo_server120719.vsps).
  • Параметры запуска echo_server (echo_server.psess):
    --port=7 --inactivity_timeout=60 --session_threads=4
  • Параметры запуска asio_performance_test_client:
    127.0.0.1 7 4 4096 10000 600 0

Тестирование asio_performance_test_client (asio_performance_test_client120719.vsps).
  • Параметры запуска asio_performance_test_client (asio_performance_test_client.psess):
    127.0.0.1 7 4 4096 10000 600 0
  • Параметры запуска qt_echo_server (кроме тех, чьи значения по умолчанию не менялись):
    Execution/Session (IO) threads: 4; Session management/Listen backlog: 10000; Session/Inactivity timeout (seconds): 60.

Буду постепенно дописывать данное сообщение. Пока выкладываю результаты как есть.

Немного поколдовал над результатами тестов: для исключения некоторых функций пришлось сделать выгрузку в Excel - echo_server120723.xls и asio_performance_test_client120723.xls (см. столбец "Elapsed Exclusive Time, fixed %").
Думал над функцией [<Unknown>] в отчете по asio_performance_test_client. Похоже, это ConnectEx - именно ее название компилятору неизвестно и именно ее вызывает функция ma::async_connect.

Updated 24.07.2012
Залил конфигурацию сборки проектов echo_server и asio_performance_test_client в SVN.
Обновил результаты тестов.
Добавил скорректированные таблицы результатов работы профилировщика в разрезе функций.

Updated 26.07.2012
Как видно из "скорректированных" таблиц результатов работы профилировщика, большую часть времени и echo_server и asio_performance_test_client проводят в системных функциях ввода-вывода (почему-то в WSASend - видимо, это связано с тем, что и сервер и клиент работали на одной и той же машине и общались через localhost) и демультиплексирования событий. По-моему, это хороший результат.

Думаю, стоит попробовать Intel VTune - интересует работа потоков.

Updated 11.08.2012
Попробовал погонять по сети и измерить VTune-ом (Core2 Duo E7200, Windows 7 x86 SP1 Pro, https://asio-samples.svn.sourceforge.net/svnroot/asio-samples/trunk@660):
Для большей наглядности почти те же данные в виде графиков:

Итоговый график для echo_server

Bottom-up для echo_server

Итоговый график для asio_performance_test_client

Bottom-up для asio_performance_test_client

Результаты, в общем-то, ожидаемо положительные и совпадают с отчетом "студийного" профилировщика. Единственное, что вызывает подозрение, это 2-х ядерный процессор. Я все еще ищу возможность использовать VTune на 8-ядерном процессоре (думаю, еще понадобится несколько n-ядерных машин, чтобы нагрузить такой сервер "под завязку").