Comments 11
Обработка в реальном времени, видео. Питон. У меня когнитивный диссонанс. Мне кажется, что-то здесь лишнее:
Вся вычислительно-сложная математика (Гильбертово преобразование, преобразования Фурье, адаптивная фильтрация и прочие преобразования) проводились в модулях на Python с помощью библиотек numpy и scipy. Из-за наличия GIL не приходилось рассчитывать на истинную многопоточность...
Кажется слова автора это подтверждают. Есть какой-то миф, что мол любая математика делается на питоне. Погодите. Лет 15 назад это ещё был фортран. Который прекрасно вызывается из C/C++. И самое смешное, что в питоне под капотом тот же C/C++/Fortran.
ActiveMQ, Mosquitto, RabbitMQ, ZeroMQ...
А оно всё зачем нужно в пределах одной вычислительной машины? Там разделяемой памяти достаточно. И любого механизма побудки второго процесса. Семафора, сокета, пайпа. Что угодно. Вплоть до сигналов. В виднах есть специальный объект "событие" (event).
Использование кольцевого буфера в shared memory
Это сразу было очевидным решением. Всё остальное, особенно ZeroMQ и т.п. -- какая-то странность.
Ну можно еще попробовать кастомный user-level tcp stack какой-нибудь :) И общение через shared memory.
Вот смотрите: у заказчика есть математик, который знает Питон и не знает C++. Математик пишет алгоритм, который решает задачу, но делает это медленно и не оптимально с точки зрения программиста. Заказчик обращается к нам и ставит задачу: сделать, чтобы быстро. И при этом он не готов и не хочет платить за портирование всей математики в плюсы, потому что математик вот он, у них, и дальнейшие правки без нас ему делать придётся.
Пробы различных MQ были направлены на сокращение времени разработки. Если есть существующее и отлаженное решение без фатальных недостатков - то зачем изобретать свой велосипед?
Непонятно зачем у вас два семафора. Я ж говорю, достаточно двух атомарных указателей (индексов, ибо адресные пространства разные) чтения и записи и механизма побудки читателя (заснувшего на пустом буфере). Зачем второй семафор для писателя? Он всегда приходит, находит следующий буфер (либо уходит ни с чем), пишет, двигает указатель записи (и потенциально будит читателя). Читатель просто читает (либо спит, если указатель чтения начинает обгонять указатель записи), двигает указатель чтения.
А почему бы не вызывать питоновский код напрямую из c++, например, через pybind11? Вообще никакого IPC не будет.
Специфика разработки для медицины очень сильно усложняет и затягивает процесс интеграции стороннего софта. Заказчик посчитал переход на стоковый питон 3.8 нецелесообразным, а тут целая опенсорсная либа.
Библиотека pybind11 это как пример, можно и без неё вызов python кода из c++ сделать, напрямую используя python.lib, просто, более муторно.
З.Ы. Даже самому интереснее, насколько это быстрее IPC.
З.З.Ы. Не знаю requirements.txt для проекта у вас, но очень вероятно, что в нём есть что-то зависящее от pybind11, т.к. этот способ связывания python <-> c++ очень распространён сейчас.
У нас получились два абсолютно независимых друг от друга приложения, которые знать ничего не знали друг о друге, да и разработка велась двумя группами программистов - плюсовики пилили одно приложение, питонисты - другое. Единственная логическая связь была посредством обсуждаемого IPC. То есть, писатель пишет в буфер, а кто именно оттуда будет читать - для него не имеет значения. Симметрично и читатель - он читает из буфера, и всё равно, кто туда пишет.
Спасибо за подсказку про pybind11, возьму на карандаш.
Что то подобное я делал давно для обработки row GPS данных с микросхемы радиоприемника под Windows Mobile на телефоне. Изначально использовался стандартный системный DMA драйвер для передачи. Но при этом терялись данные. Немного, пара бит, но этого было достаточно для рассинхронизации фреймов.
Тогда просто напрямую инициализировал DMA контроллер с тем чтобы данные поступали в кольцевой буфер из последовательного порта через scatter/gather механизм.
Высоконагруженный IPC между C++ и Python