powered by simpleCommunicator - 2.0.59     © 2025 Programmizd 02
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Форумы / C++ [игнор отключен] [закрыт для гостей] / Межпроцессное взаимодействие - что быстрее?
25 сообщений из 109, страница 2 из 5
Межпроцессное взаимодействие - что быстрее?
    #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
25 сообщений из 109, страница 2 из 5
Форумы / C++ [игнор отключен] [закрыт для гостей] / Межпроцессное взаимодействие - что быстрее?
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


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