powered by simpleCommunicator - 2.0.58     © 2025 Programmizd 02
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Форумы / C++ [игнор отключен] [закрыт для гостей] / Межпроцессное взаимодействие - что быстрее?
109 сообщений из 109, показаны все 5 страниц
Межпроцессное взаимодействие - что быстрее?
    #39623227
13th
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Какой самый быстрый способ межпроцессного взаимодействия в Windows? Надо передавать много (300..500) небольших сообщений из одного процесса в 3-5 других.
Интересует минимальная задержка и минимальная нагрузка на процессор.
Сейчас использую COM - предел производительности достигнут. Нужно что-то, что побыстрее.
...
Рейтинг: 0 / 0
Межпроцессное взаимодействие - что быстрее?
    #39623234
Фотография NekZ
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
...
Рейтинг: 0 / 0
Межпроцессное взаимодействие - что быстрее?
    #39623235
rdb_dev
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
13th, если небольших сообщений, то можно попробовать Mailslots , а в общем случае - у memory-mapped файлов конкурентов нет.
...
Рейтинг: 0 / 0
Межпроцессное взаимодействие - что быстрее?
    #39623236
13th
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
NekZ13th,

Named Pipes

Как и с чем сравнивал?
...
Рейтинг: 0 / 0
Межпроцессное взаимодействие - что быстрее?
    #39623237
13th
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
rdb_dev13th, если небольших сообщений, то можно попробовать Mailslots , а в общем случае - у memory-mapped файлов конкурентов нет.
Сообщения от 20 до 50 байт.
А как в случае файлов происходит уведомление об изменении? Там какой-то callback или через Wait-функцию?
...
Рейтинг: 0 / 0
Межпроцессное взаимодействие - что быстрее?
    #39623244
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
13thА как в случае файлов происходит уведомление об изменении?

Любым способом на который хватит больной фантазии. От "вообще никак" и критических секций
до отмашки флажками.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
Межпроцессное взаимодействие - что быстрее?
    #39623297
Фотография Anatoly Moskovsky
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
13thКакой самый быстрый способ межпроцессного взаимодействия в Windows? Надо передавать много (300..500) небольших сообщений из одного процесса в 3-5 других.
Интересует минимальная задержка и минимальная нагрузка на процессор.
Сейчас использую COM - предел производительности достигнут. Нужно что-то, что побыстрее.
Lock-free очередь через memory-mapped файл
...
Рейтинг: 0 / 0
Межпроцессное взаимодействие - что быстрее?
    #39623393
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Anatoly MoskovskyLock-free очередь через memory-mapped файл

Поток сообщений у него, пожалуй, маловат для lock-free. Процессор будет зря грузиться.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
Межпроцессное взаимодействие - что быстрее?
    #39623453
13th
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Прошу прощенья, не совсем точно написал.
Надо передавать 300..500 сообщений В СЕКУНДУ.
...
Рейтинг: 0 / 0
Межпроцессное взаимодействие - что быстрее?
    #39623488
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
13thНадо передавать 300..500 сообщений В СЕКУНДУ.

500 небольших сообщений по килобайту это полмегабайта в секунду. На этом вообще затыка
быть не может: TCP со всем его оверхэдом способно гнать мегабайты в секунду и ещё поспать
по ходу.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
Межпроцессное взаимодействие - что быстрее?
    #39623516
13th
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Dimitry Sibiryakov, 500 сообщений - это не не пол-мегабайта. 500 сообщений в 5 клиентов - это 3000 переключений контекстов процесса в секунду.
Я давно тебя просил не появляться в моих темах: у тебя поверхностный взгляд и неуместный апломб.
...
Рейтинг: 0 / 0
Межпроцессное взаимодействие - что быстрее?
    #39623518
13th
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Anatoly Moskovsky, для lock-free нужен общий менеджер памяти. Для, для межпотокового взаимодействия - самое оно. Но есть реализации для межпроцесного взаимодействия? Я не в курсе этой темы, кинь, пожалуйста, пару ссылок, с чем работал ты.
...
Рейтинг: 0 / 0
Межпроцессное взаимодействие - что быстрее?
    #39623521
Leonid Kudryavtsev
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
13thDimitry Sibiryakov, 500 сообщений - это не не пол-мегабайта. 500 сообщений в 5 клиентов - это 3000 переключений контекстов процесса в секунду.
Я давно тебя просил не появляться в моих темах: у тебя поверхностный взгляд и неуместный апломб.
И что? 500,5,3000... для IP, а тем более loopback раз плюнуть

У меня на Descktop (1 проц, 2 ядра. 4 HT ядра) под 40-50 Mb/s в 200 байтных пакетах без проблем получалось. С натяжкой > 100 Mb/s. Т.е. пара сотен тысяч IP пакетов через loopback.

Общую память и lock free очереди используют когда надо под сотню миллионов сообщений в секунду передать. AFAIK

IP через Loopback в Windows давно оптимизировано для inter process communication. По реальному Etnernet (даже 10G) скорость будет существенно меньше.
...
Рейтинг: 0 / 0
Межпроцессное взаимодействие - что быстрее?
    #39623527
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
13thдля lock-free нужен общий менеджер памяти

MMF это и есть shared memory.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
Межпроцессное взаимодействие - что быстрее?
    #39623538
13th
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Leonid Kudryavtsev, а какая задержка на пакете получается?
Мне надо сделать, что бы работало как COM сейчас: сервер - подписчики, событие - отправил пакет - обработался в процессах А, Б, В, на каждое событие.
Если скорость достигается за счёт группировки, т.е. за счёт того, что call-back вызов дёргается один раз на несколько событий - тогда не годится.
...
Рейтинг: 0 / 0
Межпроцессное взаимодействие - что быстрее?
    #39623548
Фотография Anatoly Moskovsky
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
13th500 сообщений - это не не пол-мегабайта. 500 сообщений в 5 клиентов - это 3000 переключений контекстов процесса в секунду.
Вообще если вы возьмете любой способ синхронизации, то спокойно сотни тысяч сообщений в секунду можно получить. Ради этих 500/s нет смысла морочиться с локфри.
Dimitry SibiryakovПоток сообщений у него, пожалуй, маловат для lock-free. Процессор будет зря грузиться.
Наверно да.
13thля lock-free нужен общий менеджер памяти.
Чаще всего не нужен. Обычно можно сообщения упаковывать в один непрерывный кусок памяти и просто скопировать его в очередь при отправке, а на принимающей стороне распаковать.
Сама очередь - это простой закольцованный буфер с двумя указателями - места чтения и записи.
...
Рейтинг: 0 / 0
Межпроцессное взаимодействие - что быстрее?
    #39623553
13th
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Anatoly MoskovskyВообще если вы возьмете любой способ синхронизации, то спокойно сотни тысяч сообщений в секунду можно получить. Ради этих 500/s
Ну вот, взял такой:
Сделал memory-mapped файл, пишу в него, делаю Set эвенту, в клиенте читаю. Размер структуры - тривиальный, 8 байт.
Получается 20 тысяч в секунду. Процессор i5-4440. До сотен тысяч далеко.

код сервера:
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
	for (size_t i = 0; i < uCount; i++)
	{
		data.nNumber = (int)i;
		CopyMemory((PVOID)pBuf, &data, sizeof(SData));
		
		evWrite.Set();
		evRead.WaitOne();
		evRead.Reset();
	}



код клиента:
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
		do
		{
			evWrite.WaitOne();
			CopyMemory(&data, (PVOID)pBuf, sizeof(SData));
			evWrite.Reset();
			evRead.Set();
		} while (data.cmd != ECommand::eQuit);
...
Рейтинг: 0 / 0
Межпроцессное взаимодействие - что быстрее?
    #39623569
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
13thДо сотен тысяч далеко.

Потому что у тебя очередь из одного элемента и процесс не распараллеливается от слова
"вообще". При таком подходе нет смысла разносить код в разные приложения или потоки: он
выполняется строго последовательно.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
Межпроцессное взаимодействие - что быстрее?
    #39623605
Фотография Anatoly Moskovsky
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
13thНу вот, взял такой:
Сделал memory-mapped файл, пишу в него, делаю Set эвенту, в клиенте читаю. Размер структуры - тривиальный, 8 байт.
Получается 20 тысяч в секунду. Процессор i5-4440. До сотен тысяч далеко.
Как выше уже написали здесь проблема в том что нет очереди.
Как только появляется очередь, то сигналы можно слать уже не на каждое сообщение, а только если очередь пуста/полна (а тогда и так одна из сторон простаивает и скорость сигналов не важна). А в промежутках между этим применяется обычный мьютекс.
Я в такой конфигурации получал не то что сотни тысяч - а даже миллионы в сек.
...
Рейтинг: 0 / 0
Межпроцессное взаимодействие - что быстрее?
    #39623612
kealon(Ruslan)
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Anatoly Moskovsky,

здесь проблема в

авторМне надо сделать, что бы работало как COM сейчас: сервер - подписчики, событие - отправил пакет - обработался в процессах А, Б, В, на каждое событие.
Если скорость достигается за счёт группировки, т.е. за счёт того, что call-back вызов дёргается один раз на несколько событий - тогда не годится.как только требуется ждать ответа - приходит беленький пушистый зверёк.

Ему придётся весь код в асинхронный переделывать
...
Рейтинг: 0 / 0
Межпроцессное взаимодействие - что быстрее?
    #39623629
Фотография Малыхин Сергей
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
А как же разделяемая память? https://www.google.ru/search?q=shared memory&oq=shared &aqs=chrome.2.69i57j0l5.10823j0j7&sourceid=chrome&ie=UTF-8
Что то быстрее сложно придумать =)
...
Рейтинг: 0 / 0
Межпроцессное взаимодействие - что быстрее?
    #39623644
Dima T
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ИМХО в пределах одной машины можно по UDP слать. При такой маленькой нагрузке потерь не должно быть.

Поизучай ZeroMQ - это легковесная очередь сообщений с различными стратегиями рассылки сообщений.
В форуме по дельфям ее подробно обсуждали .
...
Рейтинг: 0 / 0
Межпроцессное взаимодействие - что быстрее?
    #39623686
13th
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Ближайшая аналогия: поток котировок. Ты должен доставить котировку в несколько модулей. Один модуль считает стратегию. Второй - баланс. Третий - отчёт. Поток котировок, естественно, идёт из одного потока. Задержка в 1..1,5ms терпима. Но пересылать группами по 100 штук - уже без варика. Так же нельзя менять порядок котировок - по понятным причинам.

Anatoly MoskovskyКак выше уже написали здесь проблема в том что нет очереди.
Как только появляется очередь, то сигналы можно слать уже не на каждое сообщение, а только если очередь пуста/полна (а тогда и так одна из сторон простаивает и скорость сигналов не важна). А в промежутках между этим применяется обычный мьютекс.

Должно обрабатываться КАЖДОЕ сообщение. Никакой очереди быть не может. Если бы можно было бы группировать, я бы всё отправил один раз в секунду, и это заняло бы 10ms.
Каждое сообщение должно обрабатываться В СВОЮ ОЧЕРЕДЬ. Поэтому никакого распараллеливания отправки тоже быть не может. Клиенты и так работают параллельно.

Anatoly MoskovskyЯ в такой конфигурации получал не то что сотни тысяч - а даже миллионы в сек.
Можешь кусок кода показать?
...
Рейтинг: 0 / 0
Межпроцессное взаимодействие - что быстрее?
    #39623687
13th
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Leonid KudryavtsevИ что? 500,5,3000... для IP, а тем более loopback раз плюнуть

У меня на Descktop (1 проц, 2 ядра. 4 HT ядра) под 40-50 Mb/s в 200 байтных пакетах без проблем получалось. С натяжкой > 100 Mb/s. Т.е. пара сотен тысяч IP пакетов через loopback.

Ты имеешь ввиду обычный Winsock?
...
Рейтинг: 0 / 0
Межпроцессное взаимодействие - что быстрее?
    #39623688
13th
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Малыхин СергейА как же разделяемая память? https://www.google.ru/search?q=shared memory&oq=shared &aqs=chrome.2.69i57j0l5.10823j0j7&sourceid=chrome&ie=UTF-8
Что то быстрее сложно придумать =)
Тему прочти
...
Рейтинг: 0 / 0
Межпроцессное взаимодействие - что быстрее?
    #39623689
13th
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Dima TИМХО в пределах одной машины можно по UDP слать. При такой маленькой нагрузке потерь не должно быть.

Поизучай ZeroMQ - это легковесная очередь сообщений с различными стратегиями рассылки сообщений.
В форуме по дельфям ее подробно обсуждали .
Спасибо, поизучаю.
...
Рейтинг: 0 / 0
Межпроцессное взаимодействие - что быстрее?
    #39623690
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
13thДолжно обрабатываться КАЖДОЕ сообщение. Никакой очереди быть не может.

Э-э-э... Поясни: какая связь между этими утверждениями?

13thКаждое сообщение должно обрабатываться В СВОЮ ОЧЕРЕДЬ.
Ну так каждое сообщение и ждёт в очереди пока не будет обработано. Из середины очереди
никто не исчезнет, вне очереди никто не пролезет.

13thТы должен доставить котировку в несколько модулей. Один модуль считает
стратегию. Второй - баланс. Третий - отчёт.
Поэтому никакого распараллеливания отправки тоже быть не может.
Тебе говорят про распараллеливание обработки. Или у тебя отчёт должен подождать подсчёта
баланса и стратегии? Тогда нужны последовательные очереди.

И, кстати, ничего из сказанного не объясняет зачем у тебя отправляющий поток ждёт
окончания обработки перед посылкой следующего сообщения.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
Межпроцессное взаимодействие - что быстрее?
    #39623698
Фотография OoCc
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
13thБлижайшая аналогия: поток котировок. Ты должен доставить котировку в несколько модулей. Один модуль считает стратегию. Второй - баланс. Третий - отчёт. Поток котировок, естественно, идёт из одного потока. Задержка в 1..1,5ms терпима.
В таком случае тебе больше подходит Actor Model
...
Рейтинг: 0 / 0
Межпроцессное взаимодействие - что быстрее?
    #39623700
Dima T
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
OoCcВ таком случае тебе больше подходит Actor Model
Акторы - это очереди, сообщения и обработчики сообщений. Плюс идеология по организации архитектуры приложения.
...
Рейтинг: 0 / 0
Межпроцессное взаимодействие - что быстрее?
    #39623701
Фотография OoCc
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Dima TOoCcВ таком случае тебе больше подходит Actor Model
Акторы - это очереди, сообщения и обработчики сообщений. Плюс идеология по организации архитектуры приложения.
Всё правильно. Всё это хозяйство можно поместить в один процесс. В терминах 13th модуль - это актор.
...
Рейтинг: 0 / 0
Межпроцессное взаимодействие - что быстрее?
    #39623746
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
13thБлижайшая аналогия: поток котировок. Ты должен доставить котировку в несколько модулей. Один модуль считает стратегию. Второй - баланс. Третий - отчёт. Поток котировок, естественно, идёт из одного потока. Задержка в 1..1,5ms терпима. Но пересылать группами по 100 штук - уже без варика. Так же нельзя менять порядок котировок - по понятным причинам.

Должно обрабатываться КАЖДОЕ сообщение. Никакой очереди быть не может. Если бы можно было бы группировать, я бы всё отправил один раз в секунду, и это заняло бы 10ms.
Каждое сообщение должно обрабатываться В СВОЮ ОЧЕРЕДЬ. Поэтому никакого распараллеливания отправки тоже быть не может. Клиенты и так работают параллельно.

Из того что ты описал можно сделать следующее предположение. Есть три модуля которые обрабатывают сообщения
строго последовательно и синхронно. Видимо нужно для бизнеса. Как RPC. И никой механизм IPC не нужен. Ну по крайней мере нет мотивации
к его использованию.

Поэтому можно выбросить все эти усложнения и сделать просто 1 модуль (процесс) который обрабатывает стратегию, баланс и отчет.

За кадром остаётся вопрос как приходит котировка. Возможно здесь можно подумать об асинхронизме и потоках
но наверное там уже стоит сетевой протокол который это обеспечивает или нечто в этом роде.

Если есть какие-то другие мотивации к разделению на процессы (хот деплой?) то пожалуйста озвучь.
...
Рейтинг: 0 / 0
Межпроцессное взаимодействие - что быстрее?
    #39623920
Фотография Anatoly Moskovsky
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
13thДолжно обрабатываться КАЖДОЕ сообщение. Никакой очереди быть не может.


Ну вот ниже без очереди отправка и ожидание ответа между двумя процессами через разделяемую память.
Тут под линукс, но в винде аналогично, просто вместо mmap() по другому разделяемая память создается.
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
42.
43.
44.
45.
46.
47.
48.
49.
50.
51.
52.
53.
54.
55.
56.
57.
58.
59.
60.
61.
62.
63.
64.
65.
66.
67.
68.
69.
70.
71.
72.
73.
74.
75.
76.
77.
78.
79.
80.
81.
82.
83.
#include <iostream>
#include <sys/mman.h>
#include <boost/date_time.hpp>
#include <boost/interprocess/sync/interprocess_mutex.hpp>
#include <boost/interprocess/sync/interprocess_condition.hpp>

using namespace std;

size_t N = 100000;

using ipc_mutex = boost::interprocess::interprocess_mutex;
using ipc_cond_var = boost::interprocess::interprocess_condition;

struct IPC
{
    ipc_mutex mtx;
    ipc_cond_var cond_arg;
    ipc_cond_var cond_ret;
    size_t arg;
    size_t ret;
    bool done{true};
};

size_t send_call(IPC* ipc, size_t arg)
{
    boost::unique_lock<ipc_mutex> lock(ipc->mtx);
    ipc->arg = arg;
    ipc->done = false;
    ipc->cond_arg.notify_one();
    while (!ipc->done) {
        ipc->cond_ret.wait(lock);
    }
    return ipc->ret;
}

size_t handle_call(IPC* ipc)
{
    boost::unique_lock<ipc_mutex> lock(ipc->mtx);
    while (ipc->done) {
        ipc->cond_arg.wait(lock);
    }
    ipc->ret = ipc->arg + 1;
    ipc->done = true;
    ipc->cond_ret.notify_one();
    return ipc->ret;
}

void callee(IPC* ipc)
{
    while (1) {
        if (handle_call(ipc) == N)
            break;
    }
}

void caller(IPC* ipc)
{
    for (size_t i = 0; i < N; i++) {
        if (send_call(ipc, i) != i + 1)
            throw std::runtime_error("invalid call");
    }
}

int main(/*int argc, char* argv[]*/)
{
    IPC* ipc = (IPC*) mmap(nullptr, sizeof(IPC), PROT_READ|PROT_WRITE, MAP_SHARED|MAP_ANONYMOUS, -1, 0);
    if (!ipc)
        throw std::runtime_error("mmap failed");
    new (ipc) IPC;
    auto t1 = boost::posix_time::microsec_clock::universal_time();
    if (fork() == 0) {
        // child
        callee(ipc);
    }
    else {
        // parent
        caller(ipc);
        auto t2 = boost::posix_time::microsec_clock::universal_time();
        auto dur = t2 - t1;
        cout << "perf=" << (double)N / dur.total_milliseconds() << " K/s" << endl;
    }
    return 0;
}


На простеньком Intel Core i3 дает 90000 сообщ/сек.

13thМожешь кусок кода показать?
Лень искать. Но поверьте, если код выше, написанный за 5 минут на коленке, дает 90К/с то асинхронная обработка очереди даст на порядки большую скорость.

Кстати у вас там в вашем примере с двумя Event неэффективно используется синхронизация. Event Винды внутри это по сути mutex + condition var. Получается в вашем коде два мьютекса, тогда как для передачи сообщения и возврата результата нужен только один мьютекс (и две условных переменных).
Может поэтому тормозит.
...
Рейтинг: 0 / 0
Межпроцессное взаимодействие - что быстрее?
    #39623946
kealon(Ruslan)
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Anatoly Moskovsky,

10к/c на винде будет

прямая зависимость от скорости переключения задач планировщиком процессов
...
Рейтинг: 0 / 0
Межпроцессное взаимодействие - что быстрее?
    #39623950
Фотография Anatoly Moskovsky
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
kealon(Ruslan)10к/c на винде будет

прямая зависимость от скорости переключения задач планировщиком процессов
Вообще, если процессы разнесены по разным процессорам, то планировщик ничего особо и не переключает в этом случае.
...
Рейтинг: 0 / 0
Межпроцессное взаимодействие - что быстрее?
    #39623955
kealon(Ruslan)
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Anatoly Moskovsky,

запусти просто под виндой да проверь, у меня Win10 i7 4710HQ - больше 10к/с не выжимает

под Linux будет быстрее, как раз из-за более быстрого переключения

по поводу:
>>Вообще, если процессы разнесены по разным процессорам, то планировщик ничего особо и не переключает в этом случае.
подсчитай какова вероятность что два процесса будут работать одновременно, т.е. долю от общего времени
...
Рейтинг: 0 / 0
Межпроцессное взаимодействие - что быстрее?
    #39623958
Фотография Anatoly Moskovsky
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
kealon(Ruslan)запусти просто под виндой да проверь, у меня Win10 i7 4710HQ - больше 10к/с не выжимает
Нету винды, не на чем проверить ))
kealon(Ruslan)по поводу:
>>Вообще, если процессы разнесены по разным процессорам, то планировщик ничего особо и не переключает в этом случае.
подсчитай какова вероятность что два процесса будут работать одновременно, т.е. долю от общего времени
Ну вот у меня вышеприведенные два процесса при запуске занимают каждый по 70% от одного ядра. Каковы шансы что они выполняются на одном ядре? ))
...
Рейтинг: 0 / 0
Межпроцессное взаимодействие - что быстрее?
    #39623965
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Типичный шаблон для Unix-pipeline. Под Windows может быть не так быстро. Ну по крайней
мере я-бы проверил. Реализация достаточно дешевая и не сложная. Не нужна реализация
очереди.
Код: plaintext
1.
quotation-producer.exe | strategy.exe | balance.exe | report.exe 
...
Рейтинг: 0 / 0
Межпроцессное взаимодействие - что быстрее?
    #39623983
kealon(Ruslan)
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
mayton,

у ТС классический RPC, надо тупо ждать ответа от другого процесса: синхронно, много-много раз.

Если он модель вызова на асинхронку не поменяет, ИМХО ловить особо нечего

как костылёк можно увеличить частоту системного таймера , это ускорит его текущую реализацию без всяких доп-ужимок
...
Рейтинг: 0 / 0
Межпроцессное взаимодействие - что быстрее?
    #39624015
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Собака зарыта в его бизнес требования. Надо их читать. И зачем там COM. Я бы пересмотрел архитектуру.
...
Рейтинг: 0 / 0
Межпроцессное взаимодействие - что быстрее?
    #39624127
13th
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
maytonЕсли есть какие-то другие мотивации к разделению на процессы (хот деплой?) то пожалуйста озвучь.
Проблем две:
1. первая проблема в том, что поставщик данных - один. Я не могу в каждый процесс добавить по поставщику, т.к. сервер поддерживает только одно соединение;
2. потребитель данных - приложение, подбирающееся к лимиту USER и GDI объектов. Поэтому часть данных открывается в одном процессе, часть - в другом, часть - в третьем. До 5-7 бывает.

Разнесения источника данных и клиентов по разным процессам никак не избежать.
Переписать UI на WPF - это годы, никто в это вкладываться не будет. Тем более, решив одну проблему, это может принести других.
Все узкие места позатыкали, сейчас на очереди - межпроцессные коммуникации.
...
Рейтинг: 0 / 0
Межпроцессное взаимодействие - что быстрее?
    #39624128
13th
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
maytonСобака зарыта в его бизнес требования. Надо их читать. И зачем там COM. Я бы пересмотрел архитектуру.
Хороший совет. Если твой продукт - MS Paint. У меня чуток побольше. Эдак, на пару порядков.
...
Рейтинг: 0 / 0
Межпроцессное взаимодействие - что быстрее?
    #39624136
13th
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
kealon(Ruslan)mayton,

у ТС классический RPC, надо тупо ждать ответа от другого процесса: синхронно, много-много раз.

Если он модель вызова на асинхронку не поменяет, ИМХО ловить особо нечего

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

Нет, синхрон в примере, что бы пользоваться общей памятью.
В продукте, конечно, COM-вызовы все асинхронные.
...
Рейтинг: 0 / 0
Межпроцессное взаимодействие - что быстрее?
    #39624173
kealon(Ruslan)
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
13thНет, синхрон в примере, что бы пользоваться общей памятью.
В продукте, конечно, COM-вызовы все асинхронные.блин ..., если у тебя асинхронные то что моск уже вторую страницу морочишь с синхронизацией?
оценки нужно получить что именно тормозит.
потом маршалинг попытаться на свой заменить для узких мест, в сети вроде примеры были как это делается - IMarshal
...
Рейтинг: 0 / 0
Межпроцессное взаимодействие - что быстрее?
    #39624190
Фотография Изопропил
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
13th,

Если предел близок по user/gdi - переписать под opengl
...
Рейтинг: 0 / 0
Межпроцессное взаимодействие - что быстрее?
    #39624207
13th
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
kealon(Ruslan)13thНет, синхрон в примере, что бы пользоваться общей памятью.
В продукте, конечно, COM-вызовы все асинхронные.блин ..., если у тебя асинхронные то что моск уже вторую страницу морочишь с синхронизацией?

синхронизация нужна в пределах одного обработчика, что бы не нарушился порядок обработки. Но когда производительности не хватает, задержка нарастает, и в некоторых модулях достигает одного часа.
...
Рейтинг: 0 / 0
Межпроцессное взаимодействие - что быстрее?
    #39624243
Фотография Изопропил
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
13th,

500*3600 сообщений в очереди ждут?
...
Рейтинг: 0 / 0
Межпроцессное взаимодействие - что быстрее?
    #39624250
13th
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Изопропил, да. Но это уже когда проблема не в передаче, а в обработке.
Приёмник имеет два потока: один принимает и складывает в очередь на обработку. Второй поток берёт из очереди и обсчитывает. Иногда бывает такой тяжёлый обсчёт, что в очереди скапливается сообщения за час. Да, 500 * 3600. Тут ничего поделать нельзя.
Но профилировка показывает, что при некоторых кейсах передача сообщений занимает до 20% процессорного времени. Если, сменив технологию передачи, я снижу этот процент до 5% - будет великолепно.
...
Рейтинг: 0 / 0
Межпроцессное взаимодействие - что быстрее?
    #39624256
kealon(Ruslan)
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
13thИзопропил, да. Но это уже когда проблема не в передаче, а в обработке.
Приёмник имеет два потока: один принимает и складывает в очередь на обработку. Второй поток берёт из очереди и обсчитывает. Иногда бывает такой тяжёлый обсчёт, что в очереди скапливается сообщения за час. Да, 500 * 3600. Тут ничего поделать нельзя.
Но профилировка показывает, что при некоторых кейсах передача сообщений занимает до 20% процессорного времени. Если, сменив технологию передачи, я снижу этот процент до 5% - будет великолепно.

давай по порядку
1. вызываешь метод который ложит в очередь, синхронно?
2. ожидание отработки задачи как реализовано?
...
Рейтинг: 0 / 0
Межпроцессное взаимодействие - что быстрее?
    #39624291
13th
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
kealon(Ruslan),

COM-объект, Singleton.
Клиенты, создают сервер-синглетон, подписываются на события (Advise). Ждут данные.
Приходят данные в сервер. Он их рассылает подписчикам. Подписчики обходятся синхронно (используется connection_point_container). Подписчик, получив данные, кладёт в FIFO очередь. Другой поток подписчика выбирает данные из очереди и обрабатывает.
...
Рейтинг: 0 / 0
Межпроцессное взаимодействие - что быстрее?
    #39624346
kealon(Ruslan)
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
13thkealon(Ruslan),

COM-объект, Singleton.
Клиенты, создают сервер-синглетон, подписываются на события (Advise). Ждут данные.
Приходят данные в сервер. Он их рассылает подписчикам. Подписчики обходятся синхронно (используется connection_point_container). Подписчик, получив данные, кладёт в FIFO очередь. Другой поток подписчика выбирает данные из очереди и обрабатывает.
т.е. выходит следующее:
>>Подписчики обходятся синхронно (используется connection_point_container)
минимум ожидание двух переключений контекста на каждого клиента: Сервер->Подписчик->Сервер
>> Подписчик, получив данные, кладёт в FIFO очередь.
я так понимаю ещё миинимум 2 переключения на каждого подписчика если с серверного объекта читается: Подписчик->Сервер->Подписчик

4N переключений на одну порцию данных, много конечно...

на сервере ложишь пришедшие данные в расшаренный буфер - на 2N сократит количество переключений при получении данных от сервера

если поменяешь модель уведомлений на "оповестить всех сразу", то ещё в N раз
...
Рейтинг: 0 / 0
Межпроцессное взаимодействие - что быстрее?
    #39624353
Фотография SashaMercury
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Dima TИМХО в пределах одной машины можно по UDP слать. При такой маленькой нагрузке потерь не должно быть.

Поизучай ZeroMQ - это легковесная очередь сообщений с различными стратегиями рассылки сообщений.
В форуме по дельфям ее подробно обсуждали .

или rabbitmq
...
Рейтинг: 0 / 0
Межпроцессное взаимодействие - что быстрее?
    #39624401
Фотография Изопропил
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
kealon(Ruslan)если поменяешь модель уведомлений на "оповестить всех сразу",
Например использовать IP протокол PGM - Pragmatic General Multicast
...
Рейтинг: 0 / 0
Межпроцессное взаимодействие - что быстрее?
    #39624463
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
13th2. потребитель данных - приложение, подбирающееся к лимиту USER и GDI объектов. Поэтому часть данных открывается в одном процессе, часть - в другом, часть - в третьем. До 5-7 бывает.

Почему много GDI-объектов? В этом приложении есть какой-то графический функционал?
...
Рейтинг: 0 / 0
Межпроцессное взаимодействие - что быстрее?
    #39624472
kealon(Ruslan)
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
mayton,

Вот кстати да, очень внимательно стоит обследовать, сложно представить зачем стоит держать столько временных объектов.
Такое количество может дать нехилые тормоза
...
Рейтинг: 0 / 0
Межпроцессное взаимодействие - что быстрее?
    #39624579
13th
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
mayton, да
...
Рейтинг: 0 / 0
Межпроцессное взаимодействие - что быстрее?
    #39624587
13th
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
kealon(Ruslan)mayton,

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

Уже обследовали, все не нужное убрали. Если приложение может месяц выстоять под AppVerifier-ом, и не упасть, поверь, это что-то да значит.
...
Рейтинг: 0 / 0
Межпроцессное взаимодействие - что быстрее?
    #39624594
13th
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Изопропилkealon(Ruslan)если поменяешь модель уведомлений на "оповестить всех сразу",
Например использовать IP протокол PGM - Pragmatic General Multicast

PGM — экспериментальный протокол IETF и ещё не утверждён в качестве стандарта . Хм, не кайф сегодня сделать, а завтра переделывать.
...
Рейтинг: 0 / 0
Межпроцессное взаимодействие - что быстрее?
    #39624595
Фотография Изопропил
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
13thmayton, да

Без тысяч мелких gdi/user объектов - никак?
...
Рейтинг: 0 / 0
Межпроцессное взаимодействие - что быстрее?
    #39624603
Фотография Изопропил
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
13thИзопропилпропущено...

Например использовать IP протокол PGM - Pragmatic General Multicast

PGM — экспериментальный протокол IETF и ещё не утверждён в качестве стандарта . Хм, не кайф сегодня сделать, а завтра переделывать.
Но работает со времен XP
...
Рейтинг: 0 / 0
Межпроцессное взаимодействие - что быстрее?
    #39624630
rdb_dev
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
13thДолжно обрабатываться КАЖДОЕ сообщение. Никакой очереди быть не может. Если бы можно было бы группировать, я бы всё отправил один раз в секунду, и это заняло бы 10ms.
Каждое сообщение должно обрабатываться В СВОЮ ОЧЕРЕДЬ. Поэтому никакого распараллеливания отправки тоже быть не может. Клиенты и так работают параллельно.В таком случае, все твои компоненты завязаны на производительности друг друга и, в буквальном смысле, осуществляют синхронную обработку сообщений ожидая, пока самый тормозной компоненты обработает сообщение. Занафига?

13thБлижайшая аналогия: поток котировок. Ты должен доставить котировку в несколько модулей. Один модуль считает стратегию. Второй - баланс. Третий - отчёт. Поток котировок, естественно, идёт из одного потока. Задержка в 1..1,5ms терпима. Но пересылать группами по 100 штук - уже без варика. Так же нельзя менять порядок котировок - по понятным причинам.Пойди от обратного - используй для каждого компоненты свой memory-mapped файл, чтобы данные представляли из себя унифицированную структуру меняющегося в размере кольца сообщений, где есть начало кольца, задающееся диспетчерской программой, его размер и конец кольца - последнее сообщение, прочитанное получателем. Всё это прекрасно будет разруливаться без всякой синхронизации одними лишь командами барьеров памяти. Алгоритм работы кольца сам додумаешь.
...
Рейтинг: 0 / 0
Межпроцессное взаимодействие - что быстрее?
    #39624659
13th
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Изопропил13thmayton, да

Без тысяч мелких gdi/user объектов - никак?

Изопропил, mayton, ну кончайте вы с этим детским садом. 300Мб только СППшников, а ещё H, idl, CS, XML, XAML, Java, JScript, HTML и хрен знает ещё чего +150Мб

как вы себе представляете реализацию ваших советов? "Пересмотреть архитектуру", "переписать на open gl", "переделать без тысяч GDI-объектов"?

Вы чего, никогда программу крупнее блокнота не видели?
...
Рейтинг: 0 / 0
Межпроцессное взаимодействие - что быстрее?
    #39624665
13th
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
rdb_devВ таком случае, все твои компоненты завязаны на производительности друг друга и, в буквальном смысле, осуществляют синхронную обработку сообщений ожидая, пока самый тормозной компоненты обработает сообщение. Занафига?
Не совсем так. Есть развязка. Я писал чуть выше: приёмники принимают данные в одном потоке, обрабатывают - в другом.

rdb_devПойди от обратного - используй для каждого компоненты свой memory-mapped файл, чтобы данные представляли из себя унифицированную структуру меняющегося в размере кольца сообщений, где есть начало кольца, задающееся диспетчерской программой, его размер и конец кольца - последнее сообщение, прочитанное получателем. Всё это прекрасно будет разруливаться без всякой синхронизации одними лишь командами барьеров памяти. Алгоритм работы кольца сам додумаешь.
Подумаю, спасибо.
...
Рейтинг: 0 / 0
Межпроцессное взаимодействие - что быстрее?
    #39624679
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
13thВы чего, никогда программу крупнее блокнота не видели?

Не-а. Покажи как у тебя на экране умещаются 32к графических объектов.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
Межпроцессное взаимодействие - что быстрее?
    #39624723
kealon(Ruslan)
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
13thИзопропил, mayton, ну кончайте вы с этим детским садом. 300Мб только СППшников, а ещё H, idl, CS, XML, XAML, Java, JScript, HTML и хрен знает ещё чего +150Мб

как вы себе представляете реализацию ваших советов? "Пересмотреть архитектуру", "переписать на open gl", "переделать без тысяч GDI-объектов"?

Вы чего, никогда программу крупнее блокнота не видели?ну как бы реально, небольшой рефакторинг просто. Чем больше программа, тем этим проще и выгодннее заниматься.
...
Рейтинг: 0 / 0
Межпроцессное взаимодействие - что быстрее?
    #39624792
13th
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
kealon(Ruslan)ну как бы реально, небольшой рефакторинг просто. Чем больше программа, тем этим проще и выгодннее заниматься.
Ну вот, сейчас рефакторю IPC. Понемногу производительностью занимаемся всё время. Но "понемногу" за 5 лет набежало очень хорошо.
...
Рейтинг: 0 / 0
Межпроцессное взаимодействие - что быстрее?
    #39624919
kealon(Ruslan)
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
13th,

статистика по GDI объектам есть? чего так много создаётся
...
Рейтинг: 0 / 0
Межпроцессное взаимодействие - что быстрее?
    #39625027
13th
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
kealon(Ruslan)13th,

статистика по GDI объектам есть? чего так много создаётся

Какое это отношение имеет к топику? Статистика есть, уменьшить нельзя.
...
Рейтинг: 0 / 0
Межпроцессное взаимодействие - что быстрее?
    #39625051
Фотография Изопропил
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
13thkealon(Ruslan)13th,

статистика по GDI объектам есть? чего так много создаётся

Какое это отношение имеет к топику? Статистика есть, уменьшить нельзя.

Прямое - лишние процессы - лишние переключения контекста
...
Рейтинг: 0 / 0
Межпроцессное взаимодействие - что быстрее?
    #39625061
13th
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Anatoly MoskovskyКстати у вас там в вашем примере с двумя Event неэффективно используется синхронизация. Event Винды внутри это по сути mutex + condition var. Получается в вашем коде два мьютекса, тогда как для передачи сообщения и возврата результата нужен только один мьютекс (и две условных переменных).
Может поэтому тормозит.
Чё-то не могу придумать, как засинхронизировать сервер и N клиентов в других процессах одним мьютексом. На всяк случай: Condition variables are user-mode objects that cannot be shared across processes . Не мог бы набросать хотя бы псевдо-код?
...
Рейтинг: 0 / 0
Межпроцессное взаимодействие - что быстрее?
    #39625071
13th
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Изопропил13thпропущено...


Какое это отношение имеет к топику? Статистика есть, уменьшить нельзя.

Прямое - лишние процессы - лишние переключения контекста

Я ему про Фому - он мне про Ерёму. Я спрашиваю - как мне ускорить IPC, он мне - уменьши количество процессов. Поверь, всё уже уменьшено и оптимизирована до предела. И число GDI не уменьшить. И USER. Мне нужен быстрый IPC, а не рассказы, как у меня всё неэффективно.
...
Рейтинг: 0 / 0
Межпроцессное взаимодействие - что быстрее?
    #39625091
rdb_dev
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
13thПоверь, всё уже уменьшено и оптимизирована до предела. И число GDI не уменьшить. И USER. Мне нужен быстрый IPC, а не рассказы, как у меня всё неэффективно.Не верю! Нет предела совершенству!!!
Еще можно написать какой-нибудь драйвер с колбэками, который будет плеваться сообщениями. ;)
...
Рейтинг: 0 / 0
Межпроцессное взаимодействие - что быстрее?
    #39625171
Фотография Anatoly Moskovsky
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
13thЧё-то не могу придумать, как засинхронизировать сервер и N клиентов в других процессах одним мьютексом.
Ну во-первых на каждую пару источник-приемник - своя очередь и своя синхронизация.
Во-вторых не один мьютекс, а мьютекс + условная переменная.

13thНа всяк случай: Condition variables are user-mode objects that cannot be shared across processes . Не мог бы набросать хотя бы псевдо-код?
По всей видимости в Винде event это и есть межпроцессная условная переменная. Просто оно сделано слишком универсально и потому тормозит. В linux условная переменная - это легковесный объект, который делает только сигналы, а мьютекс к нему полагается отдельный.
Я выше приводил в примере condition из Boost .
Но выше говорили что этот код на винде тормозит на порядок по сравнению с линуксом.

По идее на основе спинлока и семафора можно реализовать что-то на подобие линуксового condition var. Но это надо думать ))

А вообще, там выше приводили пример ZeroMQ. Это библиотека как раз умеет быстро посылать сообщения между процессами.
Попробуйте ее, или посмотрите как она это делает. Хотя не исключено что под Виндой и она тормозит )))
...
Рейтинг: 0 / 0
Межпроцессное взаимодействие - что быстрее?
    #39625195
13th
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Я, вообще-то чутка подшаманил, и разогнал до 242К/сек. (1 клиент) и 143К/сек. (5 клиентов). На стандартных виндовых Event-ах.
...
Рейтинг: 0 / 0
Межпроцессное взаимодействие - что быстрее?
    #39625201
Dima T
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
13thНа стандартных виндовых Event-ах.
Критические сессии намного быстрее, но их можно только внутри одного процесса использовать.
Есть еще std::mutex, быстрая штука, но его не сравнивал с эвентами и из разных процессов не пробовал.
...
Рейтинг: 0 / 0
Межпроцессное взаимодействие - что быстрее?
    #39625204
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
13thЯ, вообще-то чутка подшаманил, и разогнал до 242К/сек. (1 клиент) и 143К/сек. (5 клиентов). На стандартных виндовых Event-ах.
Топик можно закрывать? :)
...
Рейтинг: 0 / 0
Межпроцессное взаимодействие - что быстрее?
    #39625225
13th
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
mayton13thЯ, вообще-то чутка подшаманил, и разогнал до 242К/сек. (1 клиент) и 143К/сек. (5 клиентов). На стандартных виндовых Event-ах.
Топик можно закрывать? :)
Пусть поваляется. Напишу потом результат сравнения с сокетами и ZMQ.
...
Рейтинг: 0 / 0
Межпроцессное взаимодействие - что быстрее?
    #39625267
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
...
Рейтинг: 0 / 0
Межпроцессное взаимодействие - что быстрее?
    #39625331
kealon(Ruslan)
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
13thЯ, вообще-то чутка подшаманил, и разогнал до 242К/сек. (1 клиент) и 143К/сек. (5 клиентов). На стандартных виндовых Event-ах.Стоит показать в чём шаманство для тех кто найдёт топик. Результат хоть глобально и печальный, но локально очень неплох.
...
Рейтинг: 0 / 0
Межпроцессное взаимодействие - что быстрее?
    #39625348
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Я думаю что автора ограничивает соглашение о неразглашении.

Но если бы у нас был макет - это бы придало Топику некоторую динамику.
...
Рейтинг: 0 / 0
Межпроцессное взаимодействие - что быстрее?
    #39625545
13th
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Пожалуйста, вот макет.
Рабочая конфигурация - Release x64, на других не пробовал.
...
Рейтинг: 0 / 0
Межпроцессное взаимодействие - что быстрее?
    #39625551
13th
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Для удобства сервер сам запускает клиентов. Что бы это работало, в PROJECT_PLACE впишите каталог солюшена.
В WORK_CLIENTS_COUNT впишите желаемое число клиентов (но не больше MAX_CLIENTS_COUNT). Это макет, я не заморачивался, что бы всё было удобно.
...
Рейтинг: 0 / 0
Межпроцессное взаимодействие - что быстрее?
    #39630121
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Друзья. Автор выложил сорцы. От нас нет ответа. Почему такая пассивность?
Мы все давали наперебой советы. Кто-то просмотрел код? Есть code review issues?
...
Рейтинг: 0 / 0
Межпроцессное взаимодействие - что быстрее?
    #39630822
Фотография MasterZiv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
mayton,

Мы все ушли в Телеграмм...
...
Рейтинг: 0 / 0
Межпроцессное взаимодействие - что быстрее?
    #39630830
Leonid Kudryavtsev
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
MasterZivmayton,

Мы все ушли в Телеграмм...

Все заняты настройкой VPN и анамайзеров для обхода блокировки Телеграмма? )))
...
Рейтинг: 0 / 0
Межпроцессное взаимодействие - что быстрее?
    #39630844
rdb_dev
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Leonid Kudryavtsev, вот еще... Занафига? Им проще не пользоваться.
...
Рейтинг: 0 / 0
Межпроцессное взаимодействие - что быстрее?
    #39630846
egorych
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
MasterZivmayton,

Мы все ушли в Телеграмм...и теперь выйти из него не можем)
...
Рейтинг: 0 / 0
Межпроцессное взаимодействие - что быстрее?
    #39630864
Dima T
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Цикл писателя:
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
	for (size_t i = 0; i < uCount; i++)
	{
		data.nNumber = (int)i; // Формируем сообщение
		memmap.Write(&data, sizeof(SData));
		//Sleep(1000);
		if (i % uMarkDivider == 0)
			wcout << '.';

		for (size_t j = 0; j < WORK_CLIENTS_COUNT; j++) // Будим всех читателей
			SetEvent(hWriterEvents[j]);

		WaitForMultipleObjects(WORK_CLIENTS_COUNT, hReaderEvents, true, INFINITE); // Ждем пока все прочитают

		for (size_t j = 0; j < WORK_CLIENTS_COUNT; j++) 
			ResetEvent(hReaderEvents[j]);
	}


Этот код будет работать со скоростью самого медленного читателя.
...
Рейтинг: 0 / 0
Межпроцессное взаимодействие - что быстрее?
    #39630895
Dima T
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Решение на первой странице написали 21300756
Anatoly MoskovskyКак выше уже написали здесь проблема в том что нет очереди.
Как только появляется очередь, то сигналы можно слать уже не на каждое сообщение, а только если очередь пуста/полна (а тогда и так одна из сторон простаивает и скорость сигналов не важна). А в промежутках между этим применяется обычный мьютекс.
Я в такой конфигурации получал не то что сотни тысяч - а даже миллионы в сек.
Но ТС похоже так и не понял как очередь добавить в его код.
...
Рейтинг: 0 / 0
Межпроцессное взаимодействие - что быстрее?
    #39630922
Фотография MasterZiv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
rdb_devLeonid Kudryavtsev, вот еще... Занафига? Им проще не пользоваться.

Он потрясающе удобен. Не знаю даже чем. Но удобен.
Кроме этого, там весь траффик. Там все люди.
Вебы сдохли.
...
Рейтинг: 0 / 0
Межпроцессное взаимодействие - что быстрее?
    #39631297
Dima T
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
13thНу вот, взял такой:
Сделал memory-mapped файл, пишу в него, делаю Set эвенту, в клиенте читаю. Размер структуры - тривиальный, 8 байт.
Получается 20 тысяч в секунду. Процессор i5-4440. До сотен тысяч далеко.
Затестил твой код 21311921 на своем i5-660. Процы похожие
Кол-во читателей Скорость тыс./сек11973143594
...
Рейтинг: 0 / 0
Межпроцессное взаимодействие - что быстрее?
    #39631308
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Хм... есть в этих эвентах какая-то натяжка. А мы можем хотя-бы снизить их количество?
Ну чтоб не на каждый месседж был эвент.
...
Рейтинг: 0 / 0
Межпроцессное взаимодействие - что быстрее?
    #39631316
rdb_dev
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
MasterZivrdb_devLeonid Kudryavtsev, вот еще... Занафига? Им проще не пользоваться.

Он потрясающе удобен. Не знаю даже чем. Но удобен.
Кроме этого, там весь траффик. Там все люди.
Вебы сдохли.Ну не знаю... Не пользуюсь ни viber'ом, ни whazzup'ом совсем, а скайпом пару раз в месяц. Разве что корпоративным jabber'ом регулярно.
...
Рейтинг: 0 / 0
Межпроцессное взаимодействие - что быстрее?
    #39631318
Dima T
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
maytonХм... есть в этих эвентах какая-то натяжка. А мы можем хотя-бы снизить их количество?
Ну чтоб не на каждый месседж был эвент.
Можно, но не поможет особо.
Я хотел показать что проблема вовсе не в эвентах. ТЗ:
13thНадо передавать 300..500 сообщений В СЕКУНДУ.
Всего. Даже при такой убогой передаче сами расходы на передачу займут 0.25-0.5% времени.
Тут хоть затюнингуйся - экономить особо не на чем. Тормоза у него в коде его читателей, поэтому надо схему чтения менять. Т.е. добавлять очередь, чтобы читатели не синхронно читали.
...
Рейтинг: 0 / 0
Межпроцессное взаимодействие - что быстрее?
    #39631797
Dima T
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
maytonХм... есть в этих эвентах какая-то натяжка. А мы можем хотя-бы снизить их количество?
Ну чтоб не на каждый месседж был эвент.
Там по два эвента на каждого читателя.

Думал можно сделать два эвента + счетчик, но не придумал как. Cделал два эвента + биткарта, т.е. 32/64 читателя максимум.

Скорость не сильно поменялась
Кол-во читателей Скорость тыс./сек Мой вариант тыс./сек11972013143150594117
Но к моему проще очередь прикрутить. Хотя тоже не все так просто, т.к. тут одно и тоже сообщение несколько читателей обрабатывают.
ИсходникСборка в TestMapped.exe, т.к. запускает сам себя для чтения
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
42.
43.
44.
45.
46.
47.
48.
49.
50.
51.
52.
53.
54.
55.
56.
57.
58.
59.
60.
61.
62.
63.
64.
65.
66.
67.
68.
69.
70.
71.
72.
73.
74.
75.
76.
77.
78.
79.
80.
81.
82.
83.
84.
85.
86.
87.
88.
89.
90.
91.
92.
93.
94.
95.
96.
97.
98.
99.
100.
101.
102.
103.
104.
105.
106.
107.
108.
109.
110.
111.
112.
113.
114.
115.
116.
117.
118.
119.
#include <windows.h>
#include <stdint.h>
#include <stdio.h>
#include <assert.h>

#define READER_COUNT 3
#define MESSAGE_COUNT 1000000

//*******************************************************************
//* SHARED DATA *****************************************************
//*******************************************************************

struct data_t {
	volatile int number;
	volatile long need_read;
};
#pragma data_seg("Shared")
data_t shared_data = { 0 };
#pragma data_seg()
#pragma comment(linker, "/SECTION:Shared,RWS")

//*******************************************************************
//* WRITER **********************************************************
//*******************************************************************

void writer() {
	HANDLE reader_event = OpenEvent(EVENT_ALL_ACCESS, false, "SharedMemoryReader");
	HANDLE writer_event = OpenEvent(EVENT_ALL_ACCESS, false, "SharedMemoryWriter");
	assert(reader_event != NULL && writer_event != NULL);
	long init_mask = (1 << READER_COUNT) - 1;
	printf("test: % d msg  %d readers\n", MESSAGE_COUNT, READER_COUNT);
	uint32_t t = GetTickCount();
	// Отправка сообщений
	while(shared_data.number != 0) {
		shared_data.number--; // Заполнение сообщения

		shared_data.need_read = init_mask; // Маска списка читателей

		SetEvent(reader_event); // Пробуждение читателей
		WaitForSingleObject(writer_event, INFINITE); // Ожидание завершения чтения
	}
	CloseHandle(writer_event);
	CloseHandle(reader_event);
	uint32_t time = GetTickCount() - t;
	printf("time %d msec  speed %d msg/sec\n", time, MESSAGE_COUNT * 1000 / (time == 0 ? 1 : time));
}

//*******************************************************************
//* READER **********************************************************
//*******************************************************************
void start_readers() {
	shared_data.number = MESSAGE_COUNT;
	HANDLE reader_event = CreateEvent(NULL, true, false, "SharedMemoryReader");
	HANDLE writer_event = CreateEvent(NULL, false, false, "SharedMemoryWriter");
	assert(reader_event != NULL && writer_event != NULL);
	// Запуск читателей
	for (size_t i = 0; i != READER_COUNT; i++) {
		STARTUPINFO si = { sizeof(si) };
		PROCESS_INFORMATION pi;
		char buf[1024];
		sprintf_s(buf, sizeof(buf), "TestMapped.exe %d", i);
		printf("run: %s\n", buf);
		CreateProcess(NULL, buf, NULL, NULL, FALSE, CREATE_NEW_CONSOLE, NULL, NULL, &si, &pi);
		CloseHandle(pi.hThread);
		CloseHandle(pi.hProcess);
	}
	Sleep(500);
	CloseHandle(writer_event);
	CloseHandle(reader_event);
}

// Прием сообщений
void reader(char *name) {
	long num = atoi(name);
	printf("reader#%d start ...\n", num);
	HANDLE reader_event = OpenEvent(EVENT_ALL_ACCESS, false, "SharedMemoryReader");
	HANDLE writer_event = OpenEvent(EVENT_ALL_ACCESS, false, "SharedMemoryWriter");
	assert(reader_event != NULL && writer_event != NULL);
	int64_t sum = 0;
	long mask = 1 << num, not_mask = ~mask;
	while(shared_data.number != 0) { // Последнее сообщение 0
		WaitForSingleObject(reader_event, INFINITE); // Ожидание заполнения сообщения

		if((shared_data.need_read & mask) == 0) {
			// Это сообщение уже обработано
			if(shared_data.need_read != 0) SwitchToThread();
			continue;
		}

		// Обработка сообщения
		sum += shared_data.number;

		// Снятие флага обработки
		long old;
		do {
			old = shared_data.need_read;
		} while (InterlockedCompareExchange(&shared_data.need_read, old & not_mask, old) != old);
		if (old == mask) {
			// Закончил последний читатель
			ResetEvent(reader_event);
			SetEvent(writer_event);
		}
	}
	SetEvent(writer_event);
	CloseHandle(writer_event);
	CloseHandle(reader_event);
	printf("sum = %lld\n", sum);
}

//*******************************************************************
int main(int argc, char **argv) {
	if(argc > 1) {
		reader(argv[1]);
	} else {
		start_readers();
		writer();
	}
	system("pause");
}

...
Рейтинг: 0 / 0
Межпроцессное взаимодействие - что быстрее?
    #39631820
Фотография Anatoly Moskovsky
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Dima Tодно и тоже сообщение несколько читателей обрабатывают.
Это не масштабируется.
У каждого читателя должна быть выделенная синхронизирующая структура для передачи сообщения. А писатель делает копии каждому.
Неважно очередью передается или одним экземпляром.
...
Рейтинг: 0 / 0
Межпроцессное взаимодействие - что быстрее?
    #39631893
13th
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Dima TЭтот код будет работать со скоростью самого медленного читателя.
В данном случае у меня тривиальный читатель: memcpy плюс SetEvent. Меньше не будет никак. Поэтому самые быстрые реальные читатели не обгонят этого, тривиального.
...
Рейтинг: 0 / 0
Межпроцессное взаимодействие - что быстрее?
    #39631917
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
13thВ данном случае у меня тривиальный читатель: memcpy плюс SetEvent.

Это на один SetEvent больше, чем необходимо.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
Межпроцессное взаимодействие - что быстрее?
    #39632035
Dima T
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
13thDima TЭтот код будет работать со скоростью самого медленного читателя.
В данном случае у меня тривиальный читатель: memcpy плюс SetEvent. Меньше не будет никак. Поэтому самые быстрые реальные читатели не обгонят этого, тривиального.
Тогда 10000+ сообщений в секунду гарантированно.
...
Рейтинг: 0 / 0
Межпроцессное взаимодействие - что быстрее?
    #39754389
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Давайте в качестве пятничной темы. Рассмотрим memory-map (mmap). В качестве points:

1) Размер страницы? Везде-ли 4к?
2) Ограничения. Сколько можно выделить.
3) Реализации в Windows/Unix
4) Практическое применение кроме традиционного (загрузка кода). SQLite? Другие DBMS?
5) Бенчмарки. Оптимизации.

Пока - предложения по вопросам. А топик я форкну отдельно.
...
Рейтинг: 0 / 0
Межпроцессное взаимодействие - что быстрее?
    #39754417
kealon(Ruslan)
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
mayton,

а конструктивно что предлагаешь обсуждать, реализацию базы типа ключ-значение (т.е. ассоциативного массива)?
межпроцессная очередь как видно в силу ограничений ОС на отклик, совсем несостоятельная
...
Рейтинг: 0 / 0
Межпроцессное взаимодействие - что быстрее?
    #39754456
Фотография MasterZiv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Малыхин СергейА как же разделяемая память? https://www.google.ru/search?q=shared memory&oq=shared &aqs=chrome.2.69i57j0l5.10823j0j7&sourceid=chrome&ie=UTF-8
Что то быстрее сложно придумать =)

А есть одна в Windows ?
Вместо неё Memory-mapped files.
...
Рейтинг: 0 / 0
Межпроцессное взаимодействие - что быстрее?
    #39754513
Dima T
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
maytonДавайте в качестве пятничной темы. Рассмотрим memory-map (mmap). В качестве points:

1) Размер страницы? Везде-ли 4к?
2) Ограничения. Сколько можно выделить.
3) Реализации в Windows/Unix
4) Практическое применение кроме традиционного (загрузка кода). SQLite? Другие DBMS?
5) Бенчмарки. Оптимизации.

Пока - предложения по вопросам. А топик я форкну отдельно.
1. Если не путаю это аппаратно определяется, но вроде везде страница 4К

С практическим применением проблема. Лично я не могу придумать реальную задачу для межпроцессного обмена. Тут есть одно сильное ограничение: все процессы должны быть на одном компе. А при соединении через tcp или пайпы такой проблемы нет.
С другой стороны если процессы должны много и часто обмениваться, то почему бы тогда не собрать их в один процесс, так гораздо быстрее будет работать.

В общем круг задач очень узок для такого инструмента. Например файл-серверные СУБД используемые преимущественно в пределах одного компа, т.е. SQLite. В SQLite это уже встроено.
MS SQL тоже может использовать.

Я использовал мапинг для рандомного чтения файла, чтобы не заморачиваться с постоянным перемещением указателя. Но как тесты показали чтение файла классическим способом работает быстрее.
...
Рейтинг: 0 / 0
Межпроцессное взаимодействие - что быстрее?
    #39754523
Фотография NekZ
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Dima TС другой стороны если процессы должны много и часто обмениваться, то почему бы тогда не собрать их в один процесс, так гораздо быстрее будет работать.

Например, если процессы под разные архитектуры. Пример из личной практики. Приложение десктопное x64 для обработки видео,
всё как положено, поддерживает разные форматы видео. Тут вдруг появилась нужда поддержать .mov-формат (QuickTime) на Windows
и macOS. Оказалось, что кодеки QuickTime являются только 32-разрядными. Запилили отдельный процесс под i386 дабы он грузил
видео с помощью кодеков и уже к нему обращаться за получением конкретных фреймов видео по обычным пайпам.
Уверен, что сейчас эту проблему можно решить другими средствами, без привлечения IPC.
...
Рейтинг: 0 / 0
Межпроцессное взаимодействие - что быстрее?
    #39754544
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Dima TЯ использовал мапинг для рандомного чтения файла, чтобы не заморачиваться с постоянным перемещением указателя. Но как тесты показали чтение файла классическим способом работает быстрее.
Это интересный для меня поинт. Вот хотелось-бы бенчмарк и обсудить.
В основном в виде сравнения.
...
Рейтинг: 0 / 0
Межпроцессное взаимодействие - что быстрее?
    #39754555
Dima T
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
maytonВот хотелось-бы бенчмарк и обсудить.
В основном в виде сравнения.
Уже
Исходники 18162869
Результаты 18163841 18163854
...
Рейтинг: 0 / 0
Межпроцессное взаимодействие - что быстрее?
    #39754567
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Dima TmaytonВот хотелось-бы бенчмарк и обсудить.
В основном в виде сравнения.
Уже
Исходники 18162869
Результаты 18163841 18163854
Это не то что я хотел. Тоесть мой юзкейс другой. Не к текстовой замене.
А больше к случайному дотупу к произвольному смещению. И в разрезе
чтений и записей. И чтений-записей.
...
Рейтинг: 0 / 0
Межпроцессное взаимодействие - что быстрее?
    #39754634
kolobok0
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
mayton1) Размер страницы? Везде-ли 4к?
2) Ограничения. Сколько можно выделить.
3) Реализации в Windows/Unix
4) Практическое применение кроме традиционного (загрузка кода). SQLite? Другие DBMS?
5) Бенчмарки. Оптимизации.


1) нет.
2) имхо упирается от процента свободной памяти на писюке... давно было дело - но около 70% кажется. это форточки. но окно делать большим - задач таких нема. везде до или после идёт фрагментация и её обработка.
3) ээээээ опыт по форточкам. в линуксе сильно не приходилось
4) а) свой движок объектной БД. б) логгирование. =анализ, поиск,фильтрация,само логирование. нужно логирование - запускается второй процесс. не нужен - не запускается. при этом тратиться в релизе только cakk/ret . Кстати говоря там stl - зло от слова совсем. Сплошной буффер, но хитро устроенный. Блокировка не на весь а только на управляющую инфу. Скорострельность самая шустрая выходит. в) предотвращение повторного запуска приложения(только если путь запуска совпадает)
5) уже выше отчасти сказал - правильный код по синхронизации, копированию и распределению данных в шаред-памяти.

удачи вам
(круглый)
ЗЫ
Тут прозвучали пайпы. Сразу предупреждаю об глюке который был на срез 2008 где то года в форточках. Как сейчас - хз, давно не проверял. Там есть один нюанс. Если пайпу планируется использовать как синхронизацию между асинхронными процессами - то там есть мёртвая зона при одновременном создании пайпы и ожидании её подъёма, когда она отвечает о создании ожидающей процессу, при этом она ещё не готова для прогона данных(будут потери). Проявляется при интенсивной нагрузке только, плавающая. Лечение - после установления физического контакта, прогнать логическую синхронизацию. От осей помойму не зависит (WIN32 имеется ввиду).
...
Рейтинг: 0 / 0
Межпроцессное взаимодействие - что быстрее?
    #39754935
rdb_dev
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Если писать какие-то процессы в виде DLL с заранее оговорённым интерфейсом взаимодействия, которые будут крутится внутри одного EXE, как это, к примеру, происходит с некоторыми службами Windows под svchost.exe, то проблема межпроцессного взаимодействия сводится к тривиальному вызову API функции одной DLL из другой с передачей параметров. Тут надо только определить кто и как будет подчищать память и как эту память выделять в случае, когда одна DLL'ка освобождает память, запрошенную из другой DLL'ки. К примеру, для таких случаев выделением памяти может заниматься какая-то третья DLL, экспортирующая функции выделения и освобождения памяти на своей куче.
...
Рейтинг: 0 / 0
Межпроцессное взаимодействие - что быстрее?
    #39754938
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
rdb_devЕсли писать какие-то процессы в виде DLL с заранее оговорённым интерфейсом взаимодействия,
которые будут крутится внутри одного EXE

....то межпроцессные взаимодействия отсутствуют как класс.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
109 сообщений из 109, показаны все 5 страниц
Форумы / C++ [игнор отключен] [закрыт для гостей] / Межпроцессное взаимодействие - что быстрее?
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]