|
Межпроцессное взаимодействие - что быстрее?
|
|||
---|---|---|---|
#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 |
|
Межпроцессное взаимодействие - что быстрее?
|
|||
---|---|---|---|
#18+
Dima TИМХО в пределах одной машины можно по UDP слать. При такой маленькой нагрузке потерь не должно быть. Поизучай ZeroMQ - это легковесная очередь сообщений с различными стратегиями рассылки сообщений. В форуме по дельфям ее подробно обсуждали . Спасибо, поизучаю. ... |
|||
:
Нравится:
Не нравится:
|
|||
31.03.2018, 12:41 |
|
Межпроцессное взаимодействие - что быстрее?
|
|||
---|---|---|---|
#18+
13thДолжно обрабатываться КАЖДОЕ сообщение. Никакой очереди быть не может. Э-э-э... Поясни: какая связь между этими утверждениями? 13thКаждое сообщение должно обрабатываться В СВОЮ ОЧЕРЕДЬ. Ну так каждое сообщение и ждёт в очереди пока не будет обработано. Из середины очереди никто не исчезнет, вне очереди никто не пролезет. 13thТы должен доставить котировку в несколько модулей. Один модуль считает стратегию. Второй - баланс. Третий - отчёт. Поэтому никакого распараллеливания отправки тоже быть не может. Тебе говорят про распараллеливание обработки. Или у тебя отчёт должен подождать подсчёта баланса и стратегии? Тогда нужны последовательные очереди. И, кстати, ничего из сказанного не объясняет зачем у тебя отправляющий поток ждёт окончания обработки перед посылкой следующего сообщения. Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
31.03.2018, 12:51 |
|
Межпроцессное взаимодействие - что быстрее?
|
|||
---|---|---|---|
#18+
13thБлижайшая аналогия: поток котировок. Ты должен доставить котировку в несколько модулей. Один модуль считает стратегию. Второй - баланс. Третий - отчёт. Поток котировок, естественно, идёт из одного потока. Задержка в 1..1,5ms терпима. В таком случае тебе больше подходит Actor Model ... |
|||
:
Нравится:
Не нравится:
|
|||
31.03.2018, 13:38 |
|
Межпроцессное взаимодействие - что быстрее?
|
|||
---|---|---|---|
#18+
OoCcВ таком случае тебе больше подходит Actor Model Акторы - это очереди, сообщения и обработчики сообщений. Плюс идеология по организации архитектуры приложения. ... |
|||
:
Нравится:
Не нравится:
|
|||
31.03.2018, 13:56 |
|
Межпроцессное взаимодействие - что быстрее?
|
|||
---|---|---|---|
#18+
Dima TOoCcВ таком случае тебе больше подходит Actor Model Акторы - это очереди, сообщения и обработчики сообщений. Плюс идеология по организации архитектуры приложения. Всё правильно. Всё это хозяйство можно поместить в один процесс. В терминах 13th модуль - это актор. ... |
|||
:
Нравится:
Не нравится:
|
|||
31.03.2018, 14:05 |
|
Межпроцессное взаимодействие - что быстрее?
|
|||
---|---|---|---|
#18+
13thБлижайшая аналогия: поток котировок. Ты должен доставить котировку в несколько модулей. Один модуль считает стратегию. Второй - баланс. Третий - отчёт. Поток котировок, естественно, идёт из одного потока. Задержка в 1..1,5ms терпима. Но пересылать группами по 100 штук - уже без варика. Так же нельзя менять порядок котировок - по понятным причинам. Должно обрабатываться КАЖДОЕ сообщение. Никакой очереди быть не может. Если бы можно было бы группировать, я бы всё отправил один раз в секунду, и это заняло бы 10ms. Каждое сообщение должно обрабатываться В СВОЮ ОЧЕРЕДЬ. Поэтому никакого распараллеливания отправки тоже быть не может. Клиенты и так работают параллельно. Из того что ты описал можно сделать следующее предположение. Есть три модуля которые обрабатывают сообщения строго последовательно и синхронно. Видимо нужно для бизнеса. Как RPC. И никой механизм IPC не нужен. Ну по крайней мере нет мотивации к его использованию. Поэтому можно выбросить все эти усложнения и сделать просто 1 модуль (процесс) который обрабатывает стратегию, баланс и отчет. За кадром остаётся вопрос как приходит котировка. Возможно здесь можно подумать об асинхронизме и потоках но наверное там уже стоит сетевой протокол который это обеспечивает или нечто в этом роде. Если есть какие-то другие мотивации к разделению на процессы (хот деплой?) то пожалуйста озвучь. ... |
|||
:
Нравится:
Не нравится:
|
|||
31.03.2018, 18:18 |
|
Межпроцессное взаимодействие - что быстрее?
|
|||
---|---|---|---|
#18+
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.
На простеньком Intel Core i3 дает 90000 сообщ/сек. 13thМожешь кусок кода показать? Лень искать. Но поверьте, если код выше, написанный за 5 минут на коленке, дает 90К/с то асинхронная обработка очереди даст на порядки большую скорость. Кстати у вас там в вашем примере с двумя Event неэффективно используется синхронизация. Event Винды внутри это по сути mutex + condition var. Получается в вашем коде два мьютекса, тогда как для передачи сообщения и возврата результата нужен только один мьютекс (и две условных переменных). Может поэтому тормозит. ... |
|||
:
Нравится:
Не нравится:
|
|||
01.04.2018, 18:22 |
|
Межпроцессное взаимодействие - что быстрее?
|
|||
---|---|---|---|
#18+
Anatoly Moskovsky, 10к/c на винде будет прямая зависимость от скорости переключения задач планировщиком процессов ... |
|||
:
Нравится:
Не нравится:
|
|||
01.04.2018, 21:26 |
|
Межпроцессное взаимодействие - что быстрее?
|
|||
---|---|---|---|
#18+
kealon(Ruslan)10к/c на винде будет прямая зависимость от скорости переключения задач планировщиком процессов Вообще, если процессы разнесены по разным процессорам, то планировщик ничего особо и не переключает в этом случае. ... |
|||
:
Нравится:
Не нравится:
|
|||
01.04.2018, 21:54 |
|
Межпроцессное взаимодействие - что быстрее?
|
|||
---|---|---|---|
#18+
Anatoly Moskovsky, запусти просто под виндой да проверь, у меня Win10 i7 4710HQ - больше 10к/с не выжимает под Linux будет быстрее, как раз из-за более быстрого переключения по поводу: >>Вообще, если процессы разнесены по разным процессорам, то планировщик ничего особо и не переключает в этом случае. подсчитай какова вероятность что два процесса будут работать одновременно, т.е. долю от общего времени ... |
|||
:
Нравится:
Не нравится:
|
|||
01.04.2018, 22:38 |
|
Межпроцессное взаимодействие - что быстрее?
|
|||
---|---|---|---|
#18+
kealon(Ruslan)запусти просто под виндой да проверь, у меня Win10 i7 4710HQ - больше 10к/с не выжимает Нету винды, не на чем проверить )) kealon(Ruslan)по поводу: >>Вообще, если процессы разнесены по разным процессорам, то планировщик ничего особо и не переключает в этом случае. подсчитай какова вероятность что два процесса будут работать одновременно, т.е. долю от общего времени Ну вот у меня вышеприведенные два процесса при запуске занимают каждый по 70% от одного ядра. Каковы шансы что они выполняются на одном ядре? )) ... |
|||
:
Нравится:
Не нравится:
|
|||
01.04.2018, 23:22 |
|
Межпроцессное взаимодействие - что быстрее?
|
|||
---|---|---|---|
#18+
Типичный шаблон для Unix-pipeline. Под Windows может быть не так быстро. Ну по крайней мере я-бы проверил. Реализация достаточно дешевая и не сложная. Не нужна реализация очереди. Код: plaintext 1.
... |
|||
:
Нравится:
Не нравится:
|
|||
02.04.2018, 00:53 |
|
Межпроцессное взаимодействие - что быстрее?
|
|||
---|---|---|---|
#18+
mayton, у ТС классический RPC, надо тупо ждать ответа от другого процесса: синхронно, много-много раз. Если он модель вызова на асинхронку не поменяет, ИМХО ловить особо нечего как костылёк можно увеличить частоту системного таймера , это ускорит его текущую реализацию без всяких доп-ужимок ... |
|||
:
Нравится:
Не нравится:
|
|||
02.04.2018, 07:26 |
|
Межпроцессное взаимодействие - что быстрее?
|
|||
---|---|---|---|
#18+
Собака зарыта в его бизнес требования. Надо их читать. И зачем там COM. Я бы пересмотрел архитектуру. ... |
|||
:
Нравится:
Не нравится:
|
|||
02.04.2018, 09:19 |
|
Межпроцессное взаимодействие - что быстрее?
|
|||
---|---|---|---|
#18+
maytonЕсли есть какие-то другие мотивации к разделению на процессы (хот деплой?) то пожалуйста озвучь. Проблем две: 1. первая проблема в том, что поставщик данных - один. Я не могу в каждый процесс добавить по поставщику, т.к. сервер поддерживает только одно соединение; 2. потребитель данных - приложение, подбирающееся к лимиту USER и GDI объектов. Поэтому часть данных открывается в одном процессе, часть - в другом, часть - в третьем. До 5-7 бывает. Разнесения источника данных и клиентов по разным процессам никак не избежать. Переписать UI на WPF - это годы, никто в это вкладываться не будет. Тем более, решив одну проблему, это может принести других. Все узкие места позатыкали, сейчас на очереди - межпроцессные коммуникации. ... |
|||
:
Нравится:
Не нравится:
|
|||
02.04.2018, 12:31 |
|
Межпроцессное взаимодействие - что быстрее?
|
|||
---|---|---|---|
#18+
maytonСобака зарыта в его бизнес требования. Надо их читать. И зачем там COM. Я бы пересмотрел архитектуру. Хороший совет. Если твой продукт - MS Paint. У меня чуток побольше. Эдак, на пару порядков. ... |
|||
:
Нравится:
Не нравится:
|
|||
02.04.2018, 12:33 |
|
Межпроцессное взаимодействие - что быстрее?
|
|||
---|---|---|---|
#18+
kealon(Ruslan)mayton, у ТС классический RPC, надо тупо ждать ответа от другого процесса: синхронно, много-много раз. Если он модель вызова на асинхронку не поменяет, ИМХО ловить особо нечего как костылёк можно увеличить частоту системного таймера , это ускорит его текущую реализацию без всяких доп-ужимок Нет, синхрон в примере, что бы пользоваться общей памятью. В продукте, конечно, COM-вызовы все асинхронные. ... |
|||
:
Нравится:
Не нравится:
|
|||
02.04.2018, 12:48 |
|
Межпроцессное взаимодействие - что быстрее?
|
|||
---|---|---|---|
#18+
13thНет, синхрон в примере, что бы пользоваться общей памятью. В продукте, конечно, COM-вызовы все асинхронные.блин ..., если у тебя асинхронные то что моск уже вторую страницу морочишь с синхронизацией? оценки нужно получить что именно тормозит. потом маршалинг попытаться на свой заменить для узких мест, в сети вроде примеры были как это делается - IMarshal ... |
|||
:
Нравится:
Не нравится:
|
|||
02.04.2018, 13:38 |
|
Межпроцессное взаимодействие - что быстрее?
|
|||
---|---|---|---|
#18+
13th, Если предел близок по user/gdi - переписать под opengl ... |
|||
:
Нравится:
Не нравится:
|
|||
02.04.2018, 14:14 |
|
Межпроцессное взаимодействие - что быстрее?
|
|||
---|---|---|---|
#18+
kealon(Ruslan)13thНет, синхрон в примере, что бы пользоваться общей памятью. В продукте, конечно, COM-вызовы все асинхронные.блин ..., если у тебя асинхронные то что моск уже вторую страницу морочишь с синхронизацией? синхронизация нужна в пределах одного обработчика, что бы не нарушился порядок обработки. Но когда производительности не хватает, задержка нарастает, и в некоторых модулях достигает одного часа. ... |
|||
:
Нравится:
Не нравится:
|
|||
02.04.2018, 14:52 |
|
Межпроцессное взаимодействие - что быстрее?
|
|||
---|---|---|---|
#18+
13th, 500*3600 сообщений в очереди ждут? ... |
|||
:
Нравится:
Не нравится:
|
|||
02.04.2018, 16:03 |
|
Межпроцессное взаимодействие - что быстрее?
|
|||
---|---|---|---|
#18+
Изопропил, да. Но это уже когда проблема не в передаче, а в обработке. Приёмник имеет два потока: один принимает и складывает в очередь на обработку. Второй поток берёт из очереди и обсчитывает. Иногда бывает такой тяжёлый обсчёт, что в очереди скапливается сообщения за час. Да, 500 * 3600. Тут ничего поделать нельзя. Но профилировка показывает, что при некоторых кейсах передача сообщений занимает до 20% процессорного времени. Если, сменив технологию передачи, я снижу этот процент до 5% - будет великолепно. ... |
|||
:
Нравится:
Не нравится:
|
|||
02.04.2018, 16:10 |
|
Межпроцессное взаимодействие - что быстрее?
|
|||
---|---|---|---|
#18+
13thИзопропил, да. Но это уже когда проблема не в передаче, а в обработке. Приёмник имеет два потока: один принимает и складывает в очередь на обработку. Второй поток берёт из очереди и обсчитывает. Иногда бывает такой тяжёлый обсчёт, что в очереди скапливается сообщения за час. Да, 500 * 3600. Тут ничего поделать нельзя. Но профилировка показывает, что при некоторых кейсах передача сообщений занимает до 20% процессорного времени. Если, сменив технологию передачи, я снижу этот процент до 5% - будет великолепно. давай по порядку 1. вызываешь метод который ложит в очередь, синхронно? 2. ожидание отработки задачи как реализовано? ... |
|||
:
Нравится:
Не нравится:
|
|||
02.04.2018, 16:24 |
|
Межпроцессное взаимодействие - что быстрее?
|
|||
---|---|---|---|
#18+
kealon(Ruslan), COM-объект, Singleton. Клиенты, создают сервер-синглетон, подписываются на события (Advise). Ждут данные. Приходят данные в сервер. Он их рассылает подписчикам. Подписчики обходятся синхронно (используется connection_point_container). Подписчик, получив данные, кладёт в FIFO очередь. Другой поток подписчика выбирает данные из очереди и обрабатывает. ... |
|||
:
Нравится:
Не нравится:
|
|||
02.04.2018, 17:21 |
|
Межпроцессное взаимодействие - что быстрее?
|
|||
---|---|---|---|
#18+
13thkealon(Ruslan), COM-объект, Singleton. Клиенты, создают сервер-синглетон, подписываются на события (Advise). Ждут данные. Приходят данные в сервер. Он их рассылает подписчикам. Подписчики обходятся синхронно (используется connection_point_container). Подписчик, получив данные, кладёт в FIFO очередь. Другой поток подписчика выбирает данные из очереди и обрабатывает. т.е. выходит следующее: >>Подписчики обходятся синхронно (используется connection_point_container) минимум ожидание двух переключений контекста на каждого клиента: Сервер->Подписчик->Сервер >> Подписчик, получив данные, кладёт в FIFO очередь. я так понимаю ещё миинимум 2 переключения на каждого подписчика если с серверного объекта читается: Подписчик->Сервер->Подписчик 4N переключений на одну порцию данных, много конечно... на сервере ложишь пришедшие данные в расшаренный буфер - на 2N сократит количество переключений при получении данных от сервера если поменяешь модель уведомлений на "оповестить всех сразу", то ещё в N раз ... |
|||
:
Нравится:
Не нравится:
|
|||
02.04.2018, 20:07 |
|
Межпроцессное взаимодействие - что быстрее?
|
|||
---|---|---|---|
#18+
Dima TИМХО в пределах одной машины можно по UDP слать. При такой маленькой нагрузке потерь не должно быть. Поизучай ZeroMQ - это легковесная очередь сообщений с различными стратегиями рассылки сообщений. В форуме по дельфям ее подробно обсуждали . или rabbitmq ... |
|||
:
Нравится:
Не нравится:
|
|||
02.04.2018, 21:16 |
|
Межпроцессное взаимодействие - что быстрее?
|
|||
---|---|---|---|
#18+
kealon(Ruslan)если поменяешь модель уведомлений на "оповестить всех сразу", Например использовать IP протокол PGM - Pragmatic General Multicast ... |
|||
:
Нравится:
Не нравится:
|
|||
03.04.2018, 02:34 |
|
Межпроцессное взаимодействие - что быстрее?
|
|||
---|---|---|---|
#18+
13th2. потребитель данных - приложение, подбирающееся к лимиту USER и GDI объектов. Поэтому часть данных открывается в одном процессе, часть - в другом, часть - в третьем. До 5-7 бывает. Почему много GDI-объектов? В этом приложении есть какой-то графический функционал? ... |
|||
:
Нравится:
Не нравится:
|
|||
03.04.2018, 08:54 |
|
Межпроцессное взаимодействие - что быстрее?
|
|||
---|---|---|---|
#18+
mayton, Вот кстати да, очень внимательно стоит обследовать, сложно представить зачем стоит держать столько временных объектов. Такое количество может дать нехилые тормоза ... |
|||
:
Нравится:
Не нравится:
|
|||
03.04.2018, 09:16 |
|
Межпроцессное взаимодействие - что быстрее?
|
|||
---|---|---|---|
#18+
mayton, да ... |
|||
:
Нравится:
Не нравится:
|
|||
03.04.2018, 11:18 |
|
Межпроцессное взаимодействие - что быстрее?
|
|||
---|---|---|---|
#18+
kealon(Ruslan)mayton, Вот кстати да, очень внимательно стоит обследовать, сложно представить зачем стоит держать столько временных объектов. Такое количество может дать нехилые тормоза Уже обследовали, все не нужное убрали. Если приложение может месяц выстоять под AppVerifier-ом, и не упасть, поверь, это что-то да значит. ... |
|||
:
Нравится:
Не нравится:
|
|||
03.04.2018, 11:23 |
|
Межпроцессное взаимодействие - что быстрее?
|
|||
---|---|---|---|
#18+
Изопропилkealon(Ruslan)если поменяешь модель уведомлений на "оповестить всех сразу", Например использовать IP протокол PGM - Pragmatic General Multicast PGM — экспериментальный протокол IETF и ещё не утверждён в качестве стандарта . Хм, не кайф сегодня сделать, а завтра переделывать. ... |
|||
:
Нравится:
Не нравится:
|
|||
03.04.2018, 11:26 |
|
Межпроцессное взаимодействие - что быстрее?
|
|||
---|---|---|---|
#18+
13thmayton, да Без тысяч мелких gdi/user объектов - никак? ... |
|||
:
Нравится:
Не нравится:
|
|||
03.04.2018, 11:26 |
|
Межпроцессное взаимодействие - что быстрее?
|
|||
---|---|---|---|
#18+
13thИзопропилпропущено... Например использовать IP протокол PGM - Pragmatic General Multicast PGM — экспериментальный протокол IETF и ещё не утверждён в качестве стандарта . Хм, не кайф сегодня сделать, а завтра переделывать. Но работает со времен XP ... |
|||
:
Нравится:
Не нравится:
|
|||
03.04.2018, 11:29 |
|
Межпроцессное взаимодействие - что быстрее?
|
|||
---|---|---|---|
#18+
13thДолжно обрабатываться КАЖДОЕ сообщение. Никакой очереди быть не может. Если бы можно было бы группировать, я бы всё отправил один раз в секунду, и это заняло бы 10ms. Каждое сообщение должно обрабатываться В СВОЮ ОЧЕРЕДЬ. Поэтому никакого распараллеливания отправки тоже быть не может. Клиенты и так работают параллельно.В таком случае, все твои компоненты завязаны на производительности друг друга и, в буквальном смысле, осуществляют синхронную обработку сообщений ожидая, пока самый тормозной компоненты обработает сообщение. Занафига? 13thБлижайшая аналогия: поток котировок. Ты должен доставить котировку в несколько модулей. Один модуль считает стратегию. Второй - баланс. Третий - отчёт. Поток котировок, естественно, идёт из одного потока. Задержка в 1..1,5ms терпима. Но пересылать группами по 100 штук - уже без варика. Так же нельзя менять порядок котировок - по понятным причинам.Пойди от обратного - используй для каждого компоненты свой memory-mapped файл, чтобы данные представляли из себя унифицированную структуру меняющегося в размере кольца сообщений, где есть начало кольца, задающееся диспетчерской программой, его размер и конец кольца - последнее сообщение, прочитанное получателем. Всё это прекрасно будет разруливаться без всякой синхронизации одними лишь командами барьеров памяти. Алгоритм работы кольца сам додумаешь. ... |
|||
:
Нравится:
Не нравится:
|
|||
03.04.2018, 11:55 |
|
Межпроцессное взаимодействие - что быстрее?
|
|||
---|---|---|---|
#18+
Изопропил13thmayton, да Без тысяч мелких gdi/user объектов - никак? Изопропил, mayton, ну кончайте вы с этим детским садом. 300Мб только СППшников, а ещё H, idl, CS, XML, XAML, Java, JScript, HTML и хрен знает ещё чего +150Мб как вы себе представляете реализацию ваших советов? "Пересмотреть архитектуру", "переписать на open gl", "переделать без тысяч GDI-объектов"? Вы чего, никогда программу крупнее блокнота не видели? ... |
|||
:
Нравится:
Не нравится:
|
|||
03.04.2018, 12:18 |
|
Межпроцессное взаимодействие - что быстрее?
|
|||
---|---|---|---|
#18+
rdb_devВ таком случае, все твои компоненты завязаны на производительности друг друга и, в буквальном смысле, осуществляют синхронную обработку сообщений ожидая, пока самый тормозной компоненты обработает сообщение. Занафига? Не совсем так. Есть развязка. Я писал чуть выше: приёмники принимают данные в одном потоке, обрабатывают - в другом. rdb_devПойди от обратного - используй для каждого компоненты свой memory-mapped файл, чтобы данные представляли из себя унифицированную структуру меняющегося в размере кольца сообщений, где есть начало кольца, задающееся диспетчерской программой, его размер и конец кольца - последнее сообщение, прочитанное получателем. Всё это прекрасно будет разруливаться без всякой синхронизации одними лишь командами барьеров памяти. Алгоритм работы кольца сам додумаешь. Подумаю, спасибо. ... |
|||
:
Нравится:
Не нравится:
|
|||
03.04.2018, 12:22 |
|
Межпроцессное взаимодействие - что быстрее?
|
|||
---|---|---|---|
#18+
13thВы чего, никогда программу крупнее блокнота не видели? Не-а. Покажи как у тебя на экране умещаются 32к графических объектов. Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
03.04.2018, 12:40 |
|
Межпроцессное взаимодействие - что быстрее?
|
|||
---|---|---|---|
#18+
13thИзопропил, mayton, ну кончайте вы с этим детским садом. 300Мб только СППшников, а ещё H, idl, CS, XML, XAML, Java, JScript, HTML и хрен знает ещё чего +150Мб как вы себе представляете реализацию ваших советов? "Пересмотреть архитектуру", "переписать на open gl", "переделать без тысяч GDI-объектов"? Вы чего, никогда программу крупнее блокнота не видели?ну как бы реально, небольшой рефакторинг просто. Чем больше программа, тем этим проще и выгодннее заниматься. ... |
|||
:
Нравится:
Не нравится:
|
|||
03.04.2018, 13:11 |
|
Межпроцессное взаимодействие - что быстрее?
|
|||
---|---|---|---|
#18+
kealon(Ruslan)ну как бы реально, небольшой рефакторинг просто. Чем больше программа, тем этим проще и выгодннее заниматься. Ну вот, сейчас рефакторю IPC. Понемногу производительностью занимаемся всё время. Но "понемногу" за 5 лет набежало очень хорошо. ... |
|||
:
Нравится:
Не нравится:
|
|||
03.04.2018, 13:53 |
|
Межпроцессное взаимодействие - что быстрее?
|
|||
---|---|---|---|
#18+
13th, статистика по GDI объектам есть? чего так много создаётся ... |
|||
:
Нравится:
Не нравится:
|
|||
03.04.2018, 15:06 |
|
Межпроцессное взаимодействие - что быстрее?
|
|||
---|---|---|---|
#18+
kealon(Ruslan)13th, статистика по GDI объектам есть? чего так много создаётся Какое это отношение имеет к топику? Статистика есть, уменьшить нельзя. ... |
|||
:
Нравится:
Не нравится:
|
|||
03.04.2018, 16:15 |
|
Межпроцессное взаимодействие - что быстрее?
|
|||
---|---|---|---|
#18+
13thkealon(Ruslan)13th, статистика по GDI объектам есть? чего так много создаётся Какое это отношение имеет к топику? Статистика есть, уменьшить нельзя. Прямое - лишние процессы - лишние переключения контекста ... |
|||
:
Нравится:
Не нравится:
|
|||
03.04.2018, 16:34 |
|
Межпроцессное взаимодействие - что быстрее?
|
|||
---|---|---|---|
#18+
Anatoly MoskovskyКстати у вас там в вашем примере с двумя Event неэффективно используется синхронизация. Event Винды внутри это по сути mutex + condition var. Получается в вашем коде два мьютекса, тогда как для передачи сообщения и возврата результата нужен только один мьютекс (и две условных переменных). Может поэтому тормозит. Чё-то не могу придумать, как засинхронизировать сервер и N клиентов в других процессах одним мьютексом. На всяк случай: Condition variables are user-mode objects that cannot be shared across processes . Не мог бы набросать хотя бы псевдо-код? ... |
|||
:
Нравится:
Не нравится:
|
|||
03.04.2018, 16:45 |
|
Межпроцессное взаимодействие - что быстрее?
|
|||
---|---|---|---|
#18+
Изопропил13thпропущено... Какое это отношение имеет к топику? Статистика есть, уменьшить нельзя. Прямое - лишние процессы - лишние переключения контекста Я ему про Фому - он мне про Ерёму. Я спрашиваю - как мне ускорить IPC, он мне - уменьши количество процессов. Поверь, всё уже уменьшено и оптимизирована до предела. И число GDI не уменьшить. И USER. Мне нужен быстрый IPC, а не рассказы, как у меня всё неэффективно. ... |
|||
:
Нравится:
Не нравится:
|
|||
03.04.2018, 16:50 |
|
Межпроцессное взаимодействие - что быстрее?
|
|||
---|---|---|---|
#18+
13thПоверь, всё уже уменьшено и оптимизирована до предела. И число GDI не уменьшить. И USER. Мне нужен быстрый IPC, а не рассказы, как у меня всё неэффективно.Не верю! Нет предела совершенству!!! Еще можно написать какой-нибудь драйвер с колбэками, который будет плеваться сообщениями. ;) ... |
|||
:
Нравится:
Не нравится:
|
|||
03.04.2018, 17:04 |
|
Межпроцессное взаимодействие - что быстрее?
|
|||
---|---|---|---|
#18+
13thЧё-то не могу придумать, как засинхронизировать сервер и N клиентов в других процессах одним мьютексом. Ну во-первых на каждую пару источник-приемник - своя очередь и своя синхронизация. Во-вторых не один мьютекс, а мьютекс + условная переменная. 13thНа всяк случай: Condition variables are user-mode objects that cannot be shared across processes . Не мог бы набросать хотя бы псевдо-код? По всей видимости в Винде event это и есть межпроцессная условная переменная. Просто оно сделано слишком универсально и потому тормозит. В linux условная переменная - это легковесный объект, который делает только сигналы, а мьютекс к нему полагается отдельный. Я выше приводил в примере condition из Boost . Но выше говорили что этот код на винде тормозит на порядок по сравнению с линуксом. По идее на основе спинлока и семафора можно реализовать что-то на подобие линуксового condition var. Но это надо думать )) А вообще, там выше приводили пример ZeroMQ. Это библиотека как раз умеет быстро посылать сообщения между процессами. Попробуйте ее, или посмотрите как она это делает. Хотя не исключено что под Виндой и она тормозит ))) ... |
|||
:
Нравится:
Не нравится:
|
|||
03.04.2018, 18:27 |
|
Межпроцессное взаимодействие - что быстрее?
|
|||
---|---|---|---|
#18+
Я, вообще-то чутка подшаманил, и разогнал до 242К/сек. (1 клиент) и 143К/сек. (5 клиентов). На стандартных виндовых Event-ах. ... |
|||
:
Нравится:
Не нравится:
|
|||
03.04.2018, 19:09 |
|
Межпроцессное взаимодействие - что быстрее?
|
|||
---|---|---|---|
#18+
13thНа стандартных виндовых Event-ах. Критические сессии намного быстрее, но их можно только внутри одного процесса использовать. Есть еще std::mutex, быстрая штука, но его не сравнивал с эвентами и из разных процессов не пробовал. ... |
|||
:
Нравится:
Не нравится:
|
|||
03.04.2018, 19:31 |
|
Межпроцессное взаимодействие - что быстрее?
|
|||
---|---|---|---|
#18+
13thЯ, вообще-то чутка подшаманил, и разогнал до 242К/сек. (1 клиент) и 143К/сек. (5 клиентов). На стандартных виндовых Event-ах. Топик можно закрывать? :) ... |
|||
:
Нравится:
Не нравится:
|
|||
03.04.2018, 19:34 |
|
Межпроцессное взаимодействие - что быстрее?
|
|||
---|---|---|---|
#18+
mayton13thЯ, вообще-то чутка подшаманил, и разогнал до 242К/сек. (1 клиент) и 143К/сек. (5 клиентов). На стандартных виндовых Event-ах. Топик можно закрывать? :) Пусть поваляется. Напишу потом результат сравнения с сокетами и ZMQ. ... |
|||
:
Нравится:
Не нравится:
|
|||
03.04.2018, 20:28 |
|
Межпроцессное взаимодействие - что быстрее?
|
|||
---|---|---|---|
#18+
... |
|||
:
Нравится:
Не нравится:
|
|||
03.04.2018, 23:26 |
|
Межпроцессное взаимодействие - что быстрее?
|
|||
---|---|---|---|
#18+
13thЯ, вообще-то чутка подшаманил, и разогнал до 242К/сек. (1 клиент) и 143К/сек. (5 клиентов). На стандартных виндовых Event-ах.Стоит показать в чём шаманство для тех кто найдёт топик. Результат хоть глобально и печальный, но локально очень неплох. ... |
|||
:
Нравится:
Не нравится:
|
|||
04.04.2018, 09:00 |
|
Межпроцессное взаимодействие - что быстрее?
|
|||
---|---|---|---|
#18+
Я думаю что автора ограничивает соглашение о неразглашении. Но если бы у нас был макет - это бы придало Топику некоторую динамику. ... |
|||
:
Нравится:
Не нравится:
|
|||
04.04.2018, 09:35 |
|
Межпроцессное взаимодействие - что быстрее?
|
|||
---|---|---|---|
#18+
Пожалуйста, вот макет. Рабочая конфигурация - Release x64, на других не пробовал. ... |
|||
:
Нравится:
Не нравится:
|
|||
04.04.2018, 14:50 |
|
Межпроцессное взаимодействие - что быстрее?
|
|||
---|---|---|---|
#18+
Для удобства сервер сам запускает клиентов. Что бы это работало, в PROJECT_PLACE впишите каталог солюшена. В WORK_CLIENTS_COUNT впишите желаемое число клиентов (но не больше MAX_CLIENTS_COUNT). Это макет, я не заморачивался, что бы всё было удобно. ... |
|||
:
Нравится:
Не нравится:
|
|||
04.04.2018, 14:57 |
|
Межпроцессное взаимодействие - что быстрее?
|
|||
---|---|---|---|
#18+
Друзья. Автор выложил сорцы. От нас нет ответа. Почему такая пассивность? Мы все давали наперебой советы. Кто-то просмотрел код? Есть code review issues? ... |
|||
:
Нравится:
Не нравится:
|
|||
13.04.2018, 23:24 |
|
Межпроцессное взаимодействие - что быстрее?
|
|||
---|---|---|---|
#18+
mayton, Мы все ушли в Телеграмм... ... |
|||
:
Нравится:
Не нравится:
|
|||
16.04.2018, 14:24 |
|
Межпроцессное взаимодействие - что быстрее?
|
|||
---|---|---|---|
#18+
MasterZivmayton, Мы все ушли в Телеграмм... Все заняты настройкой VPN и анамайзеров для обхода блокировки Телеграмма? ))) ... |
|||
:
Нравится:
Не нравится:
|
|||
16.04.2018, 14:36 |
|
Межпроцессное взаимодействие - что быстрее?
|
|||
---|---|---|---|
#18+
Leonid Kudryavtsev, вот еще... Занафига? Им проще не пользоваться. ... |
|||
:
Нравится:
Не нравится:
|
|||
16.04.2018, 14:47 |
|
Межпроцессное взаимодействие - что быстрее?
|
|||
---|---|---|---|
#18+
MasterZivmayton, Мы все ушли в Телеграмм...и теперь выйти из него не можем) ... |
|||
:
Нравится:
Не нравится:
|
|||
16.04.2018, 14:50 |
|
Межпроцессное взаимодействие - что быстрее?
|
|||
---|---|---|---|
#18+
Цикл писателя: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16.
Этот код будет работать со скоростью самого медленного читателя. ... |
|||
:
Нравится:
Не нравится:
|
|||
16.04.2018, 15:06 |
|
Межпроцессное взаимодействие - что быстрее?
|
|||
---|---|---|---|
#18+
Решение на первой странице написали 21300756 Anatoly MoskovskyКак выше уже написали здесь проблема в том что нет очереди. Как только появляется очередь, то сигналы можно слать уже не на каждое сообщение, а только если очередь пуста/полна (а тогда и так одна из сторон простаивает и скорость сигналов не важна). А в промежутках между этим применяется обычный мьютекс. Я в такой конфигурации получал не то что сотни тысяч - а даже миллионы в сек. Но ТС похоже так и не понял как очередь добавить в его код. ... |
|||
:
Нравится:
Не нравится:
|
|||
16.04.2018, 15:32 |
|
Межпроцессное взаимодействие - что быстрее?
|
|||
---|---|---|---|
#18+
rdb_devLeonid Kudryavtsev, вот еще... Занафига? Им проще не пользоваться. Он потрясающе удобен. Не знаю даже чем. Но удобен. Кроме этого, там весь траффик. Там все люди. Вебы сдохли. ... |
|||
:
Нравится:
Не нравится:
|
|||
16.04.2018, 16:03 |
|
Межпроцессное взаимодействие - что быстрее?
|
|||
---|---|---|---|
#18+
13thНу вот, взял такой: Сделал memory-mapped файл, пишу в него, делаю Set эвенту, в клиенте читаю. Размер структуры - тривиальный, 8 байт. Получается 20 тысяч в секунду. Процессор i5-4440. До сотен тысяч далеко. Затестил твой код 21311921 на своем i5-660. Процы похожие Кол-во читателей Скорость тыс./сек11973143594 ... |
|||
:
Нравится:
Не нравится:
|
|||
17.04.2018, 09:08 |
|
Межпроцессное взаимодействие - что быстрее?
|
|||
---|---|---|---|
#18+
Хм... есть в этих эвентах какая-то натяжка. А мы можем хотя-бы снизить их количество? Ну чтоб не на каждый месседж был эвент. ... |
|||
:
Нравится:
Не нравится:
|
|||
17.04.2018, 09:23 |
|
Межпроцессное взаимодействие - что быстрее?
|
|||
---|---|---|---|
#18+
MasterZivrdb_devLeonid Kudryavtsev, вот еще... Занафига? Им проще не пользоваться. Он потрясающе удобен. Не знаю даже чем. Но удобен. Кроме этого, там весь траффик. Там все люди. Вебы сдохли.Ну не знаю... Не пользуюсь ни viber'ом, ни whazzup'ом совсем, а скайпом пару раз в месяц. Разве что корпоративным jabber'ом регулярно. ... |
|||
:
Нравится:
Не нравится:
|
|||
17.04.2018, 09:40 |
|
Межпроцессное взаимодействие - что быстрее?
|
|||
---|---|---|---|
#18+
maytonХм... есть в этих эвентах какая-то натяжка. А мы можем хотя-бы снизить их количество? Ну чтоб не на каждый месседж был эвент. Можно, но не поможет особо. Я хотел показать что проблема вовсе не в эвентах. ТЗ: 13thНадо передавать 300..500 сообщений В СЕКУНДУ. Всего. Даже при такой убогой передаче сами расходы на передачу займут 0.25-0.5% времени. Тут хоть затюнингуйся - экономить особо не на чем. Тормоза у него в коде его читателей, поэтому надо схему чтения менять. Т.е. добавлять очередь, чтобы читатели не синхронно читали. ... |
|||
:
Нравится:
Не нравится:
|
|||
17.04.2018, 09:42 |
|
Межпроцессное взаимодействие - что быстрее?
|
|||
---|---|---|---|
#18+
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.
... |
|||
:
Нравится:
Не нравится:
|
|||
17.04.2018, 16:51 |
|
Межпроцессное взаимодействие - что быстрее?
|
|||
---|---|---|---|
#18+
Dima Tодно и тоже сообщение несколько читателей обрабатывают. Это не масштабируется. У каждого читателя должна быть выделенная синхронизирующая структура для передачи сообщения. А писатель делает копии каждому. Неважно очередью передается или одним экземпляром. ... |
|||
:
Нравится:
Не нравится:
|
|||
17.04.2018, 17:02 |
|
Межпроцессное взаимодействие - что быстрее?
|
|||
---|---|---|---|
#18+
Dima TЭтот код будет работать со скоростью самого медленного читателя. В данном случае у меня тривиальный читатель: memcpy плюс SetEvent. Меньше не будет никак. Поэтому самые быстрые реальные читатели не обгонят этого, тривиального. ... |
|||
:
Нравится:
Не нравится:
|
|||
17.04.2018, 18:04 |
|
Межпроцессное взаимодействие - что быстрее?
|
|||
---|---|---|---|
#18+
13thВ данном случае у меня тривиальный читатель: memcpy плюс SetEvent. Это на один SetEvent больше, чем необходимо. Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
17.04.2018, 18:23 |
|
Межпроцессное взаимодействие - что быстрее?
|
|||
---|---|---|---|
#18+
13thDima TЭтот код будет работать со скоростью самого медленного читателя. В данном случае у меня тривиальный читатель: memcpy плюс SetEvent. Меньше не будет никак. Поэтому самые быстрые реальные читатели не обгонят этого, тривиального. Тогда 10000+ сообщений в секунду гарантированно. ... |
|||
:
Нравится:
Не нравится:
|
|||
17.04.2018, 20:21 |
|
Межпроцессное взаимодействие - что быстрее?
|
|||
---|---|---|---|
#18+
Давайте в качестве пятничной темы. Рассмотрим memory-map (mmap). В качестве points: 1) Размер страницы? Везде-ли 4к? 2) Ограничения. Сколько можно выделить. 3) Реализации в Windows/Unix 4) Практическое применение кроме традиционного (загрузка кода). SQLite? Другие DBMS? 5) Бенчмарки. Оптимизации. Пока - предложения по вопросам. А топик я форкну отдельно. ... |
|||
:
Нравится:
Не нравится:
|
|||
28.12.2018, 10:38 |
|
Межпроцессное взаимодействие - что быстрее?
|
|||
---|---|---|---|
#18+
mayton, а конструктивно что предлагаешь обсуждать, реализацию базы типа ключ-значение (т.е. ассоциативного массива)? межпроцессная очередь как видно в силу ограничений ОС на отклик, совсем несостоятельная ... |
|||
:
Нравится:
Не нравится:
|
|||
28.12.2018, 11:13 |
|
Межпроцессное взаимодействие - что быстрее?
|
|||
---|---|---|---|
#18+
Малыхин СергейА как же разделяемая память? https://www.google.ru/search?q=shared memory&oq=shared &aqs=chrome.2.69i57j0l5.10823j0j7&sourceid=chrome&ie=UTF-8 Что то быстрее сложно придумать =) А есть одна в Windows ? Вместо неё Memory-mapped files. ... |
|||
:
Нравится:
Не нравится:
|
|||
28.12.2018, 11:55 |
|
Межпроцессное взаимодействие - что быстрее?
|
|||
---|---|---|---|
#18+
maytonДавайте в качестве пятничной темы. Рассмотрим memory-map (mmap). В качестве points: 1) Размер страницы? Везде-ли 4к? 2) Ограничения. Сколько можно выделить. 3) Реализации в Windows/Unix 4) Практическое применение кроме традиционного (загрузка кода). SQLite? Другие DBMS? 5) Бенчмарки. Оптимизации. Пока - предложения по вопросам. А топик я форкну отдельно. 1. Если не путаю это аппаратно определяется, но вроде везде страница 4К С практическим применением проблема. Лично я не могу придумать реальную задачу для межпроцессного обмена. Тут есть одно сильное ограничение: все процессы должны быть на одном компе. А при соединении через tcp или пайпы такой проблемы нет. С другой стороны если процессы должны много и часто обмениваться, то почему бы тогда не собрать их в один процесс, так гораздо быстрее будет работать. В общем круг задач очень узок для такого инструмента. Например файл-серверные СУБД используемые преимущественно в пределах одного компа, т.е. SQLite. В SQLite это уже встроено. MS SQL тоже может использовать. Я использовал мапинг для рандомного чтения файла, чтобы не заморачиваться с постоянным перемещением указателя. Но как тесты показали чтение файла классическим способом работает быстрее. ... |
|||
:
Нравится:
Не нравится:
|
|||
28.12.2018, 13:29 |
|
Межпроцессное взаимодействие - что быстрее?
|
|||
---|---|---|---|
#18+
Dima TС другой стороны если процессы должны много и часто обмениваться, то почему бы тогда не собрать их в один процесс, так гораздо быстрее будет работать. Например, если процессы под разные архитектуры. Пример из личной практики. Приложение десктопное x64 для обработки видео, всё как положено, поддерживает разные форматы видео. Тут вдруг появилась нужда поддержать .mov-формат (QuickTime) на Windows и macOS. Оказалось, что кодеки QuickTime являются только 32-разрядными. Запилили отдельный процесс под i386 дабы он грузил видео с помощью кодеков и уже к нему обращаться за получением конкретных фреймов видео по обычным пайпам. Уверен, что сейчас эту проблему можно решить другими средствами, без привлечения IPC. ... |
|||
:
Нравится:
Не нравится:
|
|||
28.12.2018, 13:37 |
|
Межпроцессное взаимодействие - что быстрее?
|
|||
---|---|---|---|
#18+
Dima TЯ использовал мапинг для рандомного чтения файла, чтобы не заморачиваться с постоянным перемещением указателя. Но как тесты показали чтение файла классическим способом работает быстрее. Это интересный для меня поинт. Вот хотелось-бы бенчмарк и обсудить. В основном в виде сравнения. ... |
|||
:
Нравится:
Не нравится:
|
|||
28.12.2018, 14:14 |
|
Межпроцессное взаимодействие - что быстрее?
|
|||
---|---|---|---|
#18+
maytonВот хотелось-бы бенчмарк и обсудить. В основном в виде сравнения. Уже Исходники 18162869 Результаты 18163841 18163854 ... |
|||
:
Нравится:
Не нравится:
|
|||
28.12.2018, 14:30 |
|
Межпроцессное взаимодействие - что быстрее?
|
|||
---|---|---|---|
#18+
Dima TmaytonВот хотелось-бы бенчмарк и обсудить. В основном в виде сравнения. Уже Исходники 18162869 Результаты 18163841 18163854 Это не то что я хотел. Тоесть мой юзкейс другой. Не к текстовой замене. А больше к случайному дотупу к произвольному смещению. И в разрезе чтений и записей. И чтений-записей. ... |
|||
:
Нравится:
Не нравится:
|
|||
28.12.2018, 14:41 |
|
Межпроцессное взаимодействие - что быстрее?
|
|||
---|---|---|---|
#18+
mayton1) Размер страницы? Везде-ли 4к? 2) Ограничения. Сколько можно выделить. 3) Реализации в Windows/Unix 4) Практическое применение кроме традиционного (загрузка кода). SQLite? Другие DBMS? 5) Бенчмарки. Оптимизации. 1) нет. 2) имхо упирается от процента свободной памяти на писюке... давно было дело - но около 70% кажется. это форточки. но окно делать большим - задач таких нема. везде до или после идёт фрагментация и её обработка. 3) ээээээ опыт по форточкам. в линуксе сильно не приходилось 4) а) свой движок объектной БД. б) логгирование. =анализ, поиск,фильтрация,само логирование. нужно логирование - запускается второй процесс. не нужен - не запускается. при этом тратиться в релизе только cakk/ret . Кстати говоря там stl - зло от слова совсем. Сплошной буффер, но хитро устроенный. Блокировка не на весь а только на управляющую инфу. Скорострельность самая шустрая выходит. в) предотвращение повторного запуска приложения(только если путь запуска совпадает) 5) уже выше отчасти сказал - правильный код по синхронизации, копированию и распределению данных в шаред-памяти. удачи вам (круглый) ЗЫ Тут прозвучали пайпы. Сразу предупреждаю об глюке который был на срез 2008 где то года в форточках. Как сейчас - хз, давно не проверял. Там есть один нюанс. Если пайпу планируется использовать как синхронизацию между асинхронными процессами - то там есть мёртвая зона при одновременном создании пайпы и ожидании её подъёма, когда она отвечает о создании ожидающей процессу, при этом она ещё не готова для прогона данных(будут потери). Проявляется при интенсивной нагрузке только, плавающая. Лечение - после установления физического контакта, прогнать логическую синхронизацию. От осей помойму не зависит (WIN32 имеется ввиду). ... |
|||
:
Нравится:
Не нравится:
|
|||
28.12.2018, 16:35 |
|
Межпроцессное взаимодействие - что быстрее?
|
|||
---|---|---|---|
#18+
Если писать какие-то процессы в виде DLL с заранее оговорённым интерфейсом взаимодействия, которые будут крутится внутри одного EXE, как это, к примеру, происходит с некоторыми службами Windows под svchost.exe, то проблема межпроцессного взаимодействия сводится к тривиальному вызову API функции одной DLL из другой с передачей параметров. Тут надо только определить кто и как будет подчищать память и как эту память выделять в случае, когда одна DLL'ка освобождает память, запрошенную из другой DLL'ки. К примеру, для таких случаев выделением памяти может заниматься какая-то третья DLL, экспортирующая функции выделения и освобождения памяти на своей куче. ... |
|||
:
Нравится:
Не нравится:
|
|||
29.12.2018, 13:59 |
|
Межпроцессное взаимодействие - что быстрее?
|
|||
---|---|---|---|
#18+
rdb_devЕсли писать какие-то процессы в виде DLL с заранее оговорённым интерфейсом взаимодействия, которые будут крутится внутри одного EXE ....то межпроцессные взаимодействия отсутствуют как класс. Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
29.12.2018, 14:05 |
|
|
start [/forum/topic.php?all=1&fid=57&tid=2017690]: |
0ms |
get settings: |
10ms |
get forum list: |
13ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
31ms |
get topic data: |
10ms |
get forum data: |
3ms |
get page messages: |
110ms |
get tp. blocked users: |
1ms |
others: | 252ms |
total: | 436ms |
0 / 0 |