Какая самая быстрая технология для отправки сообщений между процессами приложений C++ в Linux? Я смутно осознаю, что на столе лежат следующие техники:
есть ли еще способы и какой самый быстрый?
Я бы посоветовал также посмотреть на это: Как использовать общую память с Linux в C.
По сути, я бы отказался от сетевых протоколов, таких как TCP и UDP, при выполнении IPC на одной машине. Они имеют накладные расходы на пакеты и привязаны к еще большему количеству ресурсов (например, порты, петлевой интерфейс).
Хотя все приведенные выше ответы очень хороши, я думаю, нам придется обсудить, что является «самым быстрым» [и должно ли оно быть «самым быстрым» или просто «достаточно быстрым для»?]
Для БОЛЬШИХ сообщений разделяемая память, без сомнения, является очень хорошей техникой и очень полезной во многих отношениях.
Однако, если сообщения небольшие, есть недостатки, связанные с необходимостью придумывать собственный протокол передачи сообщений и метод информирования другого процесса о наличии сообщения.
Каналы и именованные каналы в этом случае намного проще использовать — они ведут себя почти как файл, вы просто записываете данные на стороне отправки и читаете данные на стороне получателя. Если отправитель что-то пишет, получатель автоматически просыпается. Если труба заполнена, отправляющая сторона блокируется. Если данных от отправителя больше нет, принимающая сторона автоматически блокируется. Это означает, что это может быть реализовано в довольно небольшом количестве строк кода с достаточно хорошей гарантией того, что оно будет работать всегда и всегда.
С другой стороны, общая память полагается на какой-то другой механизм, чтобы сообщить другому потоку, что «у вас есть пакет данных для обработки». Да, это очень быстро, если у вас есть БОЛЬШИЕ пакеты данных для копирования, но я был бы удивлен, если бы на самом деле была огромная разница с каналом. Основное преимущество заключается в том, что другой стороне не нужно копировать данные из общей памяти, но она также зависит от наличия достаточной памяти для хранения всех сообщений «в полете» или от отправителя, имеющего возможность удерживать данные. .
Я не говорю «не используйте разделяемую память», я просто говорю, что не существует такого понятия, как «одно решение, которое лучше всего решает все проблемы».
Чтобы уточнить: я бы начал с реализации простого метода с использованием канала или именованного канала [в зависимости от того, что подходит для целей] и измерил его производительность. Если значительное время тратится на копирование данных, я бы рассмотрел возможность использования других методов.
Конечно, еще одним соображением должно быть «собираемся ли мы когда-нибудь использовать две отдельные машины [или две виртуальные машины в одной системе] для решения этой проблемы. В этом случае лучше выбрать сетевое решение, даже если оно не САМОЕ быстрое». , я запустил локальный стек TCP на своих машинах на работе для тестов и получил около 20-30 Гбит / с (2-3 ГБ / с) с устойчивым трафиком.Необработанный memcpy в том же процессе дает около 50-100 ГБит / с (5-10 ГБ/с) (если только размер блока ДЕЙСТВИТЕЛЬНО крошечный и не помещается в кеш L1). Я не измерял стандартный канал, но ожидаю, что это где-то примерно посередине этих двух чисел. [Это цифры которые подходят для ряда различных довольно современных ПК среднего размера - очевидно, на ARM, MIPS или другом встроенном контроллере ожидайте меньшего числа для всех этих методов]
Исследовательская группа NetOS Systems Research из Кембриджского университета, Великобритания, провела несколько тестов IPC (с открытым исходным кодом).
Исходный код находится по адресу https://github.com/avsm/ipc-bench .
Страница проекта: http://www.cl.cam.ac.uk/research/srg/netos/projects/ipc-bench/ .
Результаты: http://www.cl.cam.ac.uk/research/srg/netos/projects/ipc-bench/results.html
Это исследование было опубликовано с использованием приведенных выше результатов: http://anil.recoil.org/papers/drafts/2012-usenix-ipc-draft1.pdf
Проверьте CMA и kdbus: https://lwn.net/Articles/466304/
Я думаю, что самые быстрые вещи в наши дни основаны на AIO. http://www.kegel.com/c10k.html
Поскольку вы пометили этот вопрос как C++, я бы рекомендовал Boost.Interprocess:
Общая память — это самый быстрый механизм межпроцессного взаимодействия. Операционная система отображает сегмент памяти в адресном пространстве нескольких процессов, так что несколько процессов могут читать и записывать в этот сегмент памяти без вызова функций операционной системы. Однако нам нужна какая-то синхронизация между процессами, читающими и записывающими разделяемую память.
Одно предостережение, которое я обнаружил, — это ограничения переносимости примитивов синхронизации. . Например, ни в OS X, ни в Windows нет собственной реализации для переменных условий межпроцессного взаимодействия, и поэтому они эмулируют их с помощью спин-блокировок.
Теперь, если вы используете *nix, который поддерживает общие примитивы процесса POSIX, проблем не будет.
Общая память с синхронизацией — хороший подход, когда речь идет о значительных объемах данных.
Ну, вы могли бы просто иметь разделяемый сегмент памяти между вашими процессами, используя линукс общая память, также известная как SHM.
Он довольно прост в использовании, посмотрите на ссылку для некоторых примеров.
очереди сообщений posix работают довольно быстро, но имеют некоторые ограничения.
