T>Вот только зачем все это? В скорость получения данных никогда ничего не упиралось, скорее в скорость передачи.
Вот изза таких взглядов и появляются потом такие темы
Здравствуйте, Teolog, Вы писали:
T>Можно, но глупо. Лучше читать в одном и распределять по потокам, как положено.
Нет, не глупо. На 10ГБ будет более миллиона пакетов в секунду, один поток не справится. Просто умрёт на переключениях контекстов.
Далее, сетевые карты в нынешний момент имеют несколько аппаратных очередей. В случае нескольких слушающих сокетов в разных потоках/процессах всё получается просто — очереди равномерно распределяться между ними. В fastpath'е в ядре там нынче даже нет никаких глобальных блокировок.
Здравствуйте, Sharov, Вы писали:
C>> Просто умрёт на переключениях контекстов. S>Каких, системных вызовов?
Их самых. Каждый recvfrom — переключение в ядро и обратно. Потом ещё полученные данные надо будет раскидать по потокам-обработчикам — ещё синхронизация.
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, Sharov, Вы писали:
C>>> Просто умрёт на переключениях контекстов. S>>Каких, системных вызовов? C>Их самых. Каждый recvfrom — переключение в ядро и обратно. Потом ещё полученные данные надо будет раскидать по потокам-обработчикам — ещё синхронизация.
Передача-lock-free очередь, ноль синхронизации и переключений контекста. Можно балансировать количество обрабатывающих потоков по длине очереди вплоть от нуля до N.
Конечно, если не предполагается пилить на коленке зверский экскаватор данных для дата-центра,что было бы крайне череповато, то на всю эту чушь можно наплевать и передавать данные через эвент и std:queue с критической секцией одному рабочему потоку.
Здравствуйте, Teolog, Вы писали:
C>>Их самых. Каждый recvfrom — переключение в ядро и обратно. Потом ещё полученные данные надо будет раскидать по потокам-обработчикам — ещё синхронизация. T>Передача-lock-free очередь, ноль синхронизации и переключений контекста. Можно балансировать количество обрабатывающих потоков по длине очереди вплоть от нуля до N.
Lock-free требует атомарных операций, которые совсем недёшевы. Кроме того, они могут местами работать медленнее обычных блокировок, если есть конкурентные чтения/запись.
Методы борьбы с этим есть (см.: disruptor), но они добавят ещё тонну сложности.
T>Конечно, если не предполагается пилить на коленке зверский экскаватор данных для дата-центра,что было бы крайне череповато, то на всю эту чушь можно наплевать и передавать данные через эвент и std:queue с критической секцией одному рабочему потоку.
Это было бы так, если несколько слушающих сокетов требовали бы гигатонны кода 80-го уровня сложности. Но в данном случае такой код будет проще кода с отдельным потоком, раскидывающим сообщения.
Здравствуйте, Cyberax, Вы писали:
C>Lock-free требует атомарных операций, которые совсем недёшевы. Кроме того, они могут местами работать медленнее обычных блокировок, если есть конкурентные чтения/запись.
Дороговизна на железном уровне -- cache coherence и т.д. А так, вполне себе метод.
Здравствуйте, Nikolay_Ch, Вы писали:
R>>если recvmsg позволяет сразу забирать по 5 дейтаграм, это лучше чем два потока будут пихаться в один recvfrom на одном сокете N_C>Вы с "параллельными" алгоритмами обработки данных знакомы? Забрать 5 сразу и потом их по очереди лопатить не всегда будет лучше, чем сделать в одном потоке забор по одной датаграмме и запустить столько потоков, сколько надо для скорости. N_C>Почему Вы считаете, что поток только делает, что забирает датаграммы? он же их еще обработать должен. Вот, пока он обрабатывает можно и другим потоком читать.
Я как раз очень понимаю топик стартера, сами сталкивались, что поток "не успевал" читать данные через recvfrom в преаллоцированные буфера и ставить эти буфера в очередь на процессинг. После долгих изысканий перешли на нативные асинхронные сокеты (винда), в юниксах такой проблемы не было.
