Накладные расходы слот-сигнал

[vulko]

Человек спросил какие проблемы могут быть если на частоте сотни в секунду в теле слота выполняется помещение а контейнер.

Наговнокодил кривой пример и продолжает из себя эксперта строить... 

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

[xokc]

Но начинать надо "от печки", т.е. с выяснения той частоты где появляется нужда в чем-то более интеллектуальном чем вязка слот-сигнал веников 

Полностью согласен. Кто готов выяснить значение частоты?

[Igors]

Полностью согласен. Кто готов выяснить значение частоты?

Так его уже выяснили. Напр если тело слота исполняется 20K/сек, то при работе с частотой 15K все хорошо, оверхед невелик. При меньшем времени исполнения слота оверхед будет расти и наоборот.

Понятно что если мы помещаем в очередь больше событий чем обработчик успевает прожевать, то очередь будет неуклонно расти, это неизбежно, оверхед слот/сигнала здесь ни при чем. Да, и Qt очередь использует стандартную схему (Q)WaitCondition.

По поводу "столкновения на мутексе" - неоднократно замечал что чем больше ниток конкурируют за него, тем хуже скорость, причем значительно. Поэтому и добавил этот тест.

Предлагаю такой вывод: основанием для отказа от (удобного) обмена с помощью слот/сигнал могут служить:

 - высокие требования к пропускной способности очереди (типа 30-40К/сек)
 - перекосы в планировании типа 10 пишут - 1 читает, также при приличной частоте   

И то и другое не так уж просто получить Напр для первого напрашивается вопрос: а чего такую мелкоту гнать через очередь в таком количестве?

[xokc]

Переформулирую и конкретизирую вопрос. Частота наполнения очереди - 10 раз в секунду, размер каждого элемента от 128 до 256 кБайт, частота чтения из неё - от 10 до 80 раз в секунду, потоков-писателей 8 шт., читатели (X шт.) объединены в пулы, пусть их количество (пулов в смысле) равно 16. Продолжительность обработки каждого элемента очереди каждым читателем - 1 мс, процессор 24-х ядерный. Чему равно Xmax при требуемой общей загруженности CPU в среднем не более 50%? Без реального моделирования это можно оценить?

[Igors]

Переформулирую и конкретизирую вопрос. Частота наполнения очереди - 10 раз в секунду, размер каждого элемента от 128 до 256 кБайт, частота чтения из неё - от 10 до 80 раз в секунду, потоков-писателей 8 шт., читатели (X шт.) объединены в пулы, пусть их количество (пулов в смысле) равно 16. Продолжительность обработки каждого элемента очереди каждым читателем - 1 мс, процессор 24-х ядерный. Чему равно Xmax при требуемой общей загруженности CPU в среднем не более 50%? Без реального моделирования это можно оценить?

При конкретно 16 читателях - полагаю ровным счетом ничего не грозит, частота слишком мала. Наверное Вы говорите об обычной/стандартной очереди на (Q)WaitCondition - в случае слот/сигнал не вижу как сделать "много читателей". Если не так понял - поправьте.

Сколько ниток-читателей выдержит? Здесь не скажу, надо проверять. Но в любом случае плодить нитки "на каждого" плохо. Не совсем ясно что здесь "пул".