Comments 26
Спасибо, было интересно!
Спасибо за статью!
Тем не менее "очень" и "весьма" спорные моменты остались.
Это ведь внешняя либа.
Потому программисты С++ и обсуждают "велосипеды", что свой код — это пара-тройка десятков строк, и уже заработало. БЕЗ внешних либ…
Вот я ровно также смотрю на libevent и пишу свой код, который по сути её дублирует.
Потому что — а как дела в solaris? freebsd? macos? win? А если это win 2000? Или хотя бы win 7? А linux? А если это redhat 5?
А если, допустим, я собираю под роутер (с его собственными заморочками, начиная от "мало памяти" и mips vs mipsel до более замороченных)?
Да, в наше время всё стало значительно проще (компиляторов три штуки — ms, gcc, clang). Платформы многие унифицировались… Но тем не менее, это всё ещё далеко не самый веский повод отказываться от "велосипедов".
что свой код — это пара-тройка десятков строк, и уже заработало. БЕЗ внешних либ…«уже заработало» в случае с многопоточностью — это, мягко говоря, наивно. Потом «пара-тройка десятков строк» очень быстро перерастает в пару-тройку тысяч. Естественно, без документации, с плохим покрытием тестами и хорошо, если автор всего этого дела еще здесь и у него есть время/желание продолжать все это поддерживать.
Еще можно понять, когда свой велосипед делается под какие-то специфические условия. Если же таковых нет, то неразумно в наше время тратить ресурсы на то, что уже давно сделано другими людьми.
А как обстоят дела с производительностью? Что будет если в канал будут писать более одного потока? А если частота генерации сигналов не милисекунды, а нонесокунды. Запись/чтение канала это lock/wait free операция или нет? Если используются атомарные операции, то насколько они оптимизрованны под текущую архитектуру?
Мне кажется подобные фреймворки полезны как раз в большей степени для новичков. Ну или для проектов, где производительность не во главе угла (хотя в этом случае плюсы наверное редко выбирают). Лично я бы не отказался от такого в свое время)
Плюсы самописного кода в том, что ты полностью понимаешь что и как там работает при тех или иных условиях.
Для ускорения разработки можно воспользоваться готовыми фреймворками, но потом вероятно нужно будет это дело оптимизировать.
Мне кажется подобные фреймворки полезны как раз в большей степени для новичков. Ну или для проектов, где производительность не во главе угла (хотя в этом случае плюсы наверное редко выбирают). Лично я бы не отказался от такого в свое время)
Плюсы самописного кода в том, что ты полностью понимаешь что и как там работает при тех или иных условиях.
Для ускорения разработки можно воспользоваться готовыми фреймворками, но потом вероятно нужно будет это дело оптимизировать.
Приведите, пожалуйста, пример случая чисто программной обработки сигнала в гигагерцовом диапазоне частот на компьютерах общего назначения?
А как обстоят дела с производительностью?Супер-мега-пупер рекордов, конечно же, не будет. Поскольку a) за операцией send в mchain скрывается, как минимум, один new для экземпляра сообщения (если же еще и сам mchain создан с политикой dynamic, а не preallocated, то может быть еще один new) и b) в качестве инструментов для синхронизации в mchain-ах сейчас используются std::mutex и std::condition_variable.
Реальную производительность нужно замерять на конкретном железе, в конкретной ОС, с конкретной версией компилятора и stdlib. Да еще и в конкретной задаче. Поскольку что-то вроде классического ping-pong-а вряд ли будет показательно и полезно.
Что будет если в канал будут писать более одного потока?В смысле? Вас интересует, как это скажется на производительности? Или возможность такой ситуации в принципе и корректность поведения mchain-а при этом?
Запись/чтение канала это lock/wait free операция или нет?На данный момент, в реализации mchain-ов используются std::mutex/std::condition_variable.
Мне кажется подобные фреймворки полезны как раз в большей степени для новичков.Не только новичков. Но и разработчиков, которые специализируются на других предметных областях, и у которых мало опыта или нет желания плотно погружаться в многопоточность.
Ну или для проектов, где производительность не во главе угла (хотя в этом случае плюсы наверное редко выбирают).Производительность — это общий термин. В приложении может считаться сложная математика и там будет более важна производительность вычислительного кода, нежели стоимость передачи сообщений между рабочими потоками.
Для ускорения разработки можно воспользоваться готовыми фреймворками, но потом вероятно нужно будет это дело оптимизировать.Это один из громадных плюсов готовых фреймворков: можно быстро получить работающий proof-of-concept, решить, стоит ли дальнейшая игра свеч и, если стоит, двинутся дальше, возможно, переписывая и оптимизируя какие-то узкие места.
Плюсы самописного кода в том, что ты полностью понимаешь что и как там работает при тех или иных условиях.решения open-source, не проблема посмореть, что там и как по сути
Для ускорения разработки можно воспользоваться готовыми фреймворками, но потом вероятно нужно будет это дело оптимизировать.— возможно, но оптимизация это все же не писать с нуля
Лично я за подобного рода фреймворки, единственное, что отталкивает от того же CAF это ну вообще не user-friendly синтаксис(((
единственное, что отталкивает от того же CAF это ну вообще не user-friendly синтаксис(((Я, конечно, сильно субъективен, но на меня CAF вообще никогда не производил впечатление практичного инструмента. Такое ощущение, что у авторов было желание максимально близко повторить в C++ Erlang, а о том, насколько это будет удобно на практике… Это был даже не второй и не третий вопрос.
Может быть будет наивным вопрос, но не отойдут ли все эти модели actor/csp/etc. на второе место в С++, когда введут аналоги async/await?
Я так не думаю. Телефонные звонки остались не смотря на появление email-ов. Сами email-ы не утратили свою актуальность не смотря на появление чатов/мессенжеров. Каждый инструмент под свою задачу. Акторы хороши там, где используется подход «послать и забыть», а так же сами акторы описываются конечными автоматами (особенно сложными КА). CSP рулит там, где нужно организовать потоковую передачу данных (вроде Unix-овых pipelines, когда мы делаем grep | xargs | tee). Async/await — это средство для task-based parallelism-а.
Все это ИМХО, конечно. Кроме того, решать прикладные задачи нужно здесь и сейчас, а не тогда, когда в стандарт C++ добавят что-то новое.
Все это ИМХО, конечно. Кроме того, решать прикладные задачи нужно здесь и сейчас, а не тогда, когда в стандарт C++ добавят что-то новое.
Согласен. Ведутся ли какие-то работы по добавлению распределения каналов на различные процессы, машины в сети, возможность минимальными усилиями подключать готовые протоколы/транспорты?
У нас есть демонстрационный проект по реализации прикладного транспорта на базе MQTT: mosquitto_transport. Мы запланировали статью на Хабре, которая расскажет об этой реализации подробнее (ориентировочно она выйдет в 20-х числах мая). Так же есть мысли сделать реализацию mchain-ов, которые позволят двум процессам на одной ноде взаимодействовать через shared-memory. Если не будет никаких неожиданностей, то начнем над этим работать через неделю-полторы, сколько времени уйдет на реализацию сейчас сложно сказать, есть еще много неисследованных вопросов в этой теме. Один из таких вопросов: насколько критично/некритично будет наличие в зависимостях у таких mchain-ов тяжелых библиотек, вроде Boost-а (скажем, Boost.Interprocess)?
А вы интересуетесь вообще или с прицелом на какую-то конкретную прикладную нишу?
А вы интересуетесь вообще или с прицелом на какую-то конкретную прикладную нишу?
Один из таких вопросов: насколько критично/некритично будет наличие в зависимостях у таких mchain-ов тяжелых библиотек, вроде Boost-а (скажем, Boost.Interprocess)?— да, вопрос значительный.
А вы интересуетесь вообще или с прицелом на какую-то конкретную прикладную нишу?— ну, мне вообще интересна область распределенных вычислений и, конечно, есть ряд прикладных задач с широким использованием многопоточности, над которыми периодически работаю. Поэтому интересуют гибкие, элегантные решения в этой области
мне вообще интересна область распределенных вычислений и, конечно, есть ряд прикладных задач, над которыми периодически работаюИнтересно, а чем уже существующие наработки в этой области не устраивают. Например, MPI тот же?
Устраивают) Но есть ряд задач для которых хотелось бы использовать высокоуровневые абстракции, например, кластеризация сложного процесса разбитого на ряд задач (pipeline, workflow), забрать на одном узле, выполнить на другом, опросить третий, отослать в четвертый и так далее… и тому подобное. Возможно, я в чем-то жесточайше заблуждаюсь)
Интересно, каков характер данных, которые вам нужно распространять между нодами? Это большие и «тяжелые» потоки двоичных данных? Непрерывный поток небольших сообщений? Эпизодические небольшие команды?
Посмотрите на HPX https://github.com/STEllAR-GROUP/hpx
Всячески поддерживаю hpx, сам хотел также ответить) Чем больше и тяжелее данные, тем меньше ценность таких абстракций, как акторы, имхо. Акторы хороши, когда надо эффективно и плотно раскидать много-много маленьких задачек по фиксированному числу физических потоков не зная заранее оптимальной стратегии планирования. Опять же имхо)
В принципе, так оно и есть. Но, опять же, от задачи зависит. Например, возьмем гипотетический почтовый сервер. Один актор может вычитывать новое письмо. Второй актор может проверять письмо на спам по black-list-ам, третий актор может проверять текст письма на спам по его содержимому, четвертый может анализировать вложения и т.д. Каждый актор может располагаться в своем собственном процессе (и даже на своей отдельной ноде).
Но это не вычислительная задача, конечно.
Но это не вычислительная задача, конечно.
Для такой задачи подойдет HPX? Бегло увидел там pipeline example…
Честно скажу, что с HPX никогда не работал, так что не знаю. Но, раз там каналы есть, то при желании можно будет подобную схему изобразить. Правда, каналы становятся не очень удобными, когда нужно вести обмен данными в обе стороны и нужно передавать сообщения разных типов. Но когда выбора нет, то это преодолевается.
Правда, каналы становятся не очень удобными, когда нужно вести обмен данными в обе стороны— mbox — это аналог channel, как эта проблема решается в SO5?
и нужно передавать сообщения разных типов.— наверное, можно ввести базовый месседж с id/type и сериализацией/десериализацией?
mbox — это аналог channel, как эта проблема решается в SO5?Не совсем так. Традиционно channel-ы делают типизированными. Скажем, channel, channel, channel, channel и т.д. У нас в SO-5 mbox/mchain «не типизированные», т.е. в один mbox/mchain можно запихивать и int, и string, и command, и reply.
наверное, можно ввести базовый месседж с id/type и сериализацией/десериализацией?Наверное, можно. Если в HPX есть возможность создавать chan, то точно можно.
Не являясь специалистом, могу сказать, что HPX ориентирована на решение вычислительных задач, включая создание вычислительных кластеров (там есть расширенная «распределенная» адресация, позволяющая «прозрачно» обращаться к удаленным данным. Основа организации конкурентности в HPX — future continuation. Каналы подчинены задаче передачи данных между нодами кластера. Но я могу все перепутать, впрочем.
Sign up to leave a comment.
Обмен информацией между рабочими нитям без боли? CSP-шные каналы нам в помощь