|
Межпроцессное взаимодействие - что быстрее?
|
|||
---|---|---|---|
#18+
Какой самый быстрый способ межпроцессного взаимодействия в Windows? Надо передавать много (300..500) небольших сообщений из одного процесса в 3-5 других. Интересует минимальная задержка и минимальная нагрузка на процессор. Сейчас использую COM - предел производительности достигнут. Нужно что-то, что побыстрее. ... |
|||
:
Нравится:
Не нравится:
|
|||
30.03.2018, 12:48 |
|
Межпроцессное взаимодействие - что быстрее?
|
|||
---|---|---|---|
#18+
... |
|||
:
Нравится:
Не нравится:
|
|||
30.03.2018, 12:53 |
|
Межпроцессное взаимодействие - что быстрее?
|
|||
---|---|---|---|
#18+
13th, если небольших сообщений, то можно попробовать Mailslots , а в общем случае - у memory-mapped файлов конкурентов нет. ... |
|||
:
Нравится:
Не нравится:
|
|||
30.03.2018, 12:55 |
|
Межпроцессное взаимодействие - что быстрее?
|
|||
---|---|---|---|
#18+
... |
|||
:
Нравится:
Не нравится:
|
|||
30.03.2018, 12:57 |
|
Межпроцессное взаимодействие - что быстрее?
|
|||
---|---|---|---|
#18+
rdb_dev13th, если небольших сообщений, то можно попробовать Mailslots , а в общем случае - у memory-mapped файлов конкурентов нет. Сообщения от 20 до 50 байт. А как в случае файлов происходит уведомление об изменении? Там какой-то callback или через Wait-функцию? ... |
|||
:
Нравится:
Не нравится:
|
|||
30.03.2018, 12:59 |
|
Межпроцессное взаимодействие - что быстрее?
|
|||
---|---|---|---|
#18+
13thА как в случае файлов происходит уведомление об изменении? Любым способом на который хватит больной фантазии. От "вообще никак" и критических секций до отмашки флажками. Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
30.03.2018, 13:10 |
|
Межпроцессное взаимодействие - что быстрее?
|
|||
---|---|---|---|
#18+
13thКакой самый быстрый способ межпроцессного взаимодействия в Windows? Надо передавать много (300..500) небольших сообщений из одного процесса в 3-5 других. Интересует минимальная задержка и минимальная нагрузка на процессор. Сейчас использую COM - предел производительности достигнут. Нужно что-то, что побыстрее. Lock-free очередь через memory-mapped файл ... |
|||
:
Нравится:
Не нравится:
|
|||
30.03.2018, 14:18 |
|
Межпроцессное взаимодействие - что быстрее?
|
|||
---|---|---|---|
#18+
Anatoly MoskovskyLock-free очередь через memory-mapped файл Поток сообщений у него, пожалуй, маловат для lock-free. Процессор будет зря грузиться. Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
30.03.2018, 15:46 |
|
Межпроцессное взаимодействие - что быстрее?
|
|||
---|---|---|---|
#18+
Прошу прощенья, не совсем точно написал. Надо передавать 300..500 сообщений В СЕКУНДУ. ... |
|||
:
Нравится:
Не нравится:
|
|||
30.03.2018, 16:45 |
|
Межпроцессное взаимодействие - что быстрее?
|
|||
---|---|---|---|
#18+
13thНадо передавать 300..500 сообщений В СЕКУНДУ. 500 небольших сообщений по килобайту это полмегабайта в секунду. На этом вообще затыка быть не может: TCP со всем его оверхэдом способно гнать мегабайты в секунду и ещё поспать по ходу. Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
30.03.2018, 17:10 |
|
Межпроцессное взаимодействие - что быстрее?
|
|||
---|---|---|---|
#18+
Dimitry Sibiryakov, 500 сообщений - это не не пол-мегабайта. 500 сообщений в 5 клиентов - это 3000 переключений контекстов процесса в секунду. Я давно тебя просил не появляться в моих темах: у тебя поверхностный взгляд и неуместный апломб. ... |
|||
:
Нравится:
Не нравится:
|
|||
30.03.2018, 17:45 |
|
Межпроцессное взаимодействие - что быстрее?
|
|||
---|---|---|---|
#18+
Anatoly Moskovsky, для lock-free нужен общий менеджер памяти. Для, для межпотокового взаимодействия - самое оно. Но есть реализации для межпроцесного взаимодействия? Я не в курсе этой темы, кинь, пожалуйста, пару ссылок, с чем работал ты. ... |
|||
:
Нравится:
Не нравится:
|
|||
30.03.2018, 17:47 |
|
Межпроцессное взаимодействие - что быстрее?
|
|||
---|---|---|---|
#18+
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) скорость будет существенно меньше. ... |
|||
:
Нравится:
Не нравится:
|
|||
30.03.2018, 17:53 |
|
Межпроцессное взаимодействие - что быстрее?
|
|||
---|---|---|---|
#18+
13thдля lock-free нужен общий менеджер памяти MMF это и есть shared memory. Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
30.03.2018, 18:09 |
|
Межпроцессное взаимодействие - что быстрее?
|
|||
---|---|---|---|
#18+
Leonid Kudryavtsev, а какая задержка на пакете получается? Мне надо сделать, что бы работало как COM сейчас: сервер - подписчики, событие - отправил пакет - обработался в процессах А, Б, В, на каждое событие. Если скорость достигается за счёт группировки, т.е. за счёт того, что call-back вызов дёргается один раз на несколько событий - тогда не годится. ... |
|||
:
Нравится:
Не нравится:
|
|||
30.03.2018, 18:42 |
|
Межпроцессное взаимодействие - что быстрее?
|
|||
---|---|---|---|
#18+
13th500 сообщений - это не не пол-мегабайта. 500 сообщений в 5 клиентов - это 3000 переключений контекстов процесса в секунду. Вообще если вы возьмете любой способ синхронизации, то спокойно сотни тысяч сообщений в секунду можно получить. Ради этих 500/s нет смысла морочиться с локфри. Dimitry SibiryakovПоток сообщений у него, пожалуй, маловат для lock-free. Процессор будет зря грузиться. Наверно да. 13thля lock-free нужен общий менеджер памяти. Чаще всего не нужен. Обычно можно сообщения упаковывать в один непрерывный кусок памяти и просто скопировать его в очередь при отправке, а на принимающей стороне распаковать. Сама очередь - это простой закольцованный буфер с двумя указателями - места чтения и записи. ... |
|||
:
Нравится:
Не нравится:
|
|||
30.03.2018, 19:18 |
|
Межпроцессное взаимодействие - что быстрее?
|
|||
---|---|---|---|
#18+
Anatoly MoskovskyВообще если вы возьмете любой способ синхронизации, то спокойно сотни тысяч сообщений в секунду можно получить. Ради этих 500/s Ну вот, взял такой: Сделал memory-mapped файл, пишу в него, делаю Set эвенту, в клиенте читаю. Размер структуры - тривиальный, 8 байт. Получается 20 тысяч в секунду. Процессор i5-4440. До сотен тысяч далеко. код сервера: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9.
код клиента: Код: plaintext 1. 2. 3. 4. 5. 6. 7.
... |
|||
:
Нравится:
Не нравится:
|
|||
30.03.2018, 19:28 |
|
Межпроцессное взаимодействие - что быстрее?
|
|||
---|---|---|---|
#18+
13thДо сотен тысяч далеко. Потому что у тебя очередь из одного элемента и процесс не распараллеливается от слова "вообще". При таком подходе нет смысла разносить код в разные приложения или потоки: он выполняется строго последовательно. Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
30.03.2018, 20:14 |
|
Межпроцессное взаимодействие - что быстрее?
|
|||
---|---|---|---|
#18+
13thНу вот, взял такой: Сделал memory-mapped файл, пишу в него, делаю Set эвенту, в клиенте читаю. Размер структуры - тривиальный, 8 байт. Получается 20 тысяч в секунду. Процессор i5-4440. До сотен тысяч далеко. Как выше уже написали здесь проблема в том что нет очереди. Как только появляется очередь, то сигналы можно слать уже не на каждое сообщение, а только если очередь пуста/полна (а тогда и так одна из сторон простаивает и скорость сигналов не важна). А в промежутках между этим применяется обычный мьютекс. Я в такой конфигурации получал не то что сотни тысяч - а даже миллионы в сек. ... |
|||
:
Нравится:
Не нравится:
|
|||
30.03.2018, 23:34 |
|
Межпроцессное взаимодействие - что быстрее?
|
|||
---|---|---|---|
#18+
Anatoly Moskovsky, здесь проблема в авторМне надо сделать, что бы работало как COM сейчас: сервер - подписчики, событие - отправил пакет - обработался в процессах А, Б, В, на каждое событие. Если скорость достигается за счёт группировки, т.е. за счёт того, что call-back вызов дёргается один раз на несколько событий - тогда не годится.как только требуется ждать ответа - приходит беленький пушистый зверёк. Ему придётся весь код в асинхронный переделывать ... |
|||
:
Нравится:
Не нравится:
|
|||
31.03.2018, 00:45 |
|
Межпроцессное взаимодействие - что быстрее?
|
|||
---|---|---|---|
#18+
А как же разделяемая память? https://www.google.ru/search?q=shared memory&oq=shared &aqs=chrome.2.69i57j0l5.10823j0j7&sourceid=chrome&ie=UTF-8 Что то быстрее сложно придумать =) ... |
|||
:
Нравится:
Не нравится:
|
|||
31.03.2018, 04:04 |
|
Межпроцессное взаимодействие - что быстрее?
|
|||
---|---|---|---|
#18+
ИМХО в пределах одной машины можно по UDP слать. При такой маленькой нагрузке потерь не должно быть. Поизучай ZeroMQ - это легковесная очередь сообщений с различными стратегиями рассылки сообщений. В форуме по дельфям ее подробно обсуждали . ... |
|||
:
Нравится:
Не нравится:
|
|||
31.03.2018, 08:01 |
|
Межпроцессное взаимодействие - что быстрее?
|
|||
---|---|---|---|
#18+
Ближайшая аналогия: поток котировок. Ты должен доставить котировку в несколько модулей. Один модуль считает стратегию. Второй - баланс. Третий - отчёт. Поток котировок, естественно, идёт из одного потока. Задержка в 1..1,5ms терпима. Но пересылать группами по 100 штук - уже без варика. Так же нельзя менять порядок котировок - по понятным причинам. Anatoly MoskovskyКак выше уже написали здесь проблема в том что нет очереди. Как только появляется очередь, то сигналы можно слать уже не на каждое сообщение, а только если очередь пуста/полна (а тогда и так одна из сторон простаивает и скорость сигналов не важна). А в промежутках между этим применяется обычный мьютекс. Должно обрабатываться КАЖДОЕ сообщение. Никакой очереди быть не может. Если бы можно было бы группировать, я бы всё отправил один раз в секунду, и это заняло бы 10ms. Каждое сообщение должно обрабатываться В СВОЮ ОЧЕРЕДЬ. Поэтому никакого распараллеливания отправки тоже быть не может. Клиенты и так работают параллельно. Anatoly MoskovskyЯ в такой конфигурации получал не то что сотни тысяч - а даже миллионы в сек. Можешь кусок кода показать? ... |
|||
:
Нравится:
Не нравится:
|
|||
31.03.2018, 12:36 |
|
Межпроцессное взаимодействие - что быстрее?
|
|||
---|---|---|---|
#18+
Leonid KudryavtsevИ что? 500,5,3000... для IP, а тем более loopback раз плюнуть У меня на Descktop (1 проц, 2 ядра. 4 HT ядра) под 40-50 Mb/s в 200 байтных пакетах без проблем получалось. С натяжкой > 100 Mb/s. Т.е. пара сотен тысяч IP пакетов через loopback. Ты имеешь ввиду обычный Winsock? ... |
|||
:
Нравится:
Не нравится:
|
|||
31.03.2018, 12:38 |
|
Межпроцессное взаимодействие - что быстрее?
|
|||
---|---|---|---|
#18+
Малыхин СергейА как же разделяемая память? https://www.google.ru/search?q=shared memory&oq=shared &aqs=chrome.2.69i57j0l5.10823j0j7&sourceid=chrome&ie=UTF-8 Что то быстрее сложно придумать =) Тему прочти ... |
|||
:
Нравится:
Не нравится:
|
|||
31.03.2018, 12:40 |
|
|
start [/forum/topic.php?fid=57&msg=39623244&tid=2017690]: |
0ms |
get settings: |
10ms |
get forum list: |
11ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
21ms |
get topic data: |
9ms |
get forum data: |
3ms |
get page messages: |
51ms |
get tp. blocked users: |
1ms |
others: | 257ms |
total: | 369ms |
0 / 0 |