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

[Igors]

Добрый день

Понятно что тема эта жевалась еще много лет назад, но поиском по форуму не пользовался. Начну сомневаться, перепроверять, в итоге не хватит времени и заглохнет на неопределенный срок. Поэтому как есть.

При каком конкретно времени исполнения слота (вкупе с частотой сигналов) эти расходы становятся ощутимыми? Конечно результат зависит от машины, платформы и версии Qt. Для данных ниже; скромный Хeon 2.66, 4 ядра, Qt 4.7.4, OSX 10.7.5 и даже Debug build.

Что и как меряем
Сначала вызываем тело слота (нагрузку) напрямую и засекаем сколько раз оно выполнилось в секунду. Затем испускаем такое же кол-во сигналов (неск способами) в секунду и смотрим сколько раз сработал слот в секунду. Отношение этих 2 замеров и даст оверхед. Понятно что если нагрузка достаточно велика - никакого оверхеда вообще не увидим. Поэтому тестировались 2 задачи

а) "min Job"  (холостой ход) тело слота почти пустое. Ну ++ к паре счетчиков, if (раз в 10К) и печать раз в секунду. Ну плюс деструктор аргумента QStringList (сводится к имплисит шаре)

b) "1K Job" то же что "a" но добавлено изменения QStringList (100 строк по 10 символов), теперь он уже будет реально скопирован и удален.  

Результаты холостого хода

--------- Test min Job ------------

Test 1 direct call:
received/sec 13424576.0
received/sec 13580420.0
received/sec 13573427.0
received/sec 13577423.0
total received = 54210000

Test 2 direct signal:
received/sec 1644355.6
received/sec 1664335.6
received/sec 1664335.6
received/sec 1664335.6
total received = 6644000

Test 3 queued signal:
received/sec 90367.4
received/sec 95378.6
received/sec 104685.9
received/sec 110889.1
total received = 404000

Тут ничего особенного, Понятно что DirectConnection чего-то весит, QueuedConnection еще больше

Test 4 queued signal multi-sender:
received/sec 9442.9
received/sec 9624.6
received/sec 9182.7
received/sec 10018.2
total received = 41000

А вот тут уже интереснее. То же число сигналов посылается не одной. а 3-мя нитками. Ядер хватает, но скорость резко упала, ведь за мутекс дерутся уже не 2 а 4 нитки. Что будет дальше (при большем числе "испускающих") - не проверял

Результаты небольшой нагрузки

--------- Test 1K Job ------------

Test 1 direct call:
received/sec 21526.4
received/sec 21442.5
received/sec 21442.5
received/sec 21421.6
total received = 88000

Test 2 direct signal:
received/sec 21317.8
received/sec 21153.8
received/sec 21174.2
received/sec 21153.8
total received = 88000

Test 3 queued signal:
received/sec 19802.0
received/sec 19665.7
received/sec 19120.5
received/sec 19743.3
total received = 80000

Test 4 queued signal multi-sender:
received/sec 9132.4
received/sec 9242.1
received/sec 9311.0
received/sec 9389.7
total received = 40000

Вполне ожидаемо - чем больше нагрузка, тем стабильнее. Разница Direct/Queued уже невелика, но проседание на последнем тесте все еще вдвое. Хотя кто знает, может это я где-то ошибся

Остальное см в прилагаемых исходниках.

Ну вот, я кажется начал писать блоги  

[kuzulis]

А ты в development (или interest) рассылку кинь это все. Мож там что-то конкретное ответят про проседание и прочее. А то тут много всяких "комментаторов" сейчас понабежит.

[qate]

если гдето ответят - отпишись тут )

а если завести 4 qeventloop-a и в каждом бросать сигналы и ловить слоты - может ядра загрузятся ?

[vulko]

А вот тут уже интереснее. То же число сигналов посылается не одной. а 3-мя нитками. Ядер хватает, но скорость резко упала, ведь за мутекс дерутся уже не 2 а 4 нитки. Что будет дальше (при большем числе "испускающих") - не проверял

Это вот эта глобальная (ахтунг!) переменная - мьютекс, то?)))

Код:

QSemaphore theSemaphore;

Да и вообще непонятно что тут замеряется и в чем вопрос?

Разница между DirectConnection и QueuedConnection ровно в том что, первое выполнит слот в потоке в котором был сигнал, а второе выполнит слот в потоке где живет объект, у которого он вызывается. Вызов через event loop и соотв. отсюда и разница во времени выполнения.

А "проседания", которые вовсе не проседания, а разные типы выполнения слотов, сильно зависят от кода. В данном случае он такой, в другом случае другие цифры будут.

[xokc]

Да и вообще непонятно что тут замеряется и в чем вопрос?

Что замеряется понятно, а вот в чем вопрос, действительно, не понятно. 

[vulko]

Да и вообще непонятно что тут замеряется и в чем вопрос?

Что замеряется понятно, а вот в чем вопрос, действительно, не понятно. 

Понятно?) Точно?)

А вот тут уже интереснее. То же число сигналов посылается не одной. а 3-мя нитками. Ядер хватает, но скорость резко упала, ведь за мутекс дерутся уже не 2 а 4 нитки. Что будет дальше (при большем числе "испускающих") - не проверял

Откуда 2-а?
NUM_SENDER = 1 в исходниках.


Небольшой тизер...

Код:

void CReceiver::SlotGet( QStringList lst )
{
	if (mNumPrint >= NUM_PRINT) return;
	
	if (mJobID == JOB_1K)
		for (int i = 0; i < lst.size(); ++i)
			lst[i][0] = 'B';

	++mCount;
	++mTotal;
	if (mCount % 1000 * 10) return;
	int delta = mTime.elapsed();                                            // <------------------------------- конец замера
	if (delta > 1000) {
		printf("received/sec %.1f\n", mCount * 1000.0f / delta);
		mCount = 0;
		mTime.restart();                                                     // <------------------------------- начало замера
		++mNumPrint;
		if (mNumPrint >= NUM_PRINT)
			theSemaphore.release();
	}
}

Тут весь проект сделан через не то место.
Нормальные замеры делают так - 1 000 000 вызовов directcall, 1 000 000 queuedconnection.
Замеряется время затраченное в первом и во втором случае. Далее 1 000 000 вызовов делится на количество секунд, и получается количество вызовов в секунду.
А тут что? А когда потоков сендеров >1 тут вообще полный писец.


И что же в итоге замеряется? Как полное отсутсвие хоть сколь-нибудь продуманной архитектуры сказывается на производительности?

[Пантер]

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

31742 - прямой вызов
32637 - direct
34128 - queue

Это затраченное время в мс на 1000000 итераций.

[vulko]

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

31742 - прямой вызов
32637 - direct
34128 - queue

Это затраченное время в мс на 1000000 итераций.

Это не совсем корректно.
Лучше делать замеры между вызовом emit signal и непосредственным вызовом slot'а.

[Пантер]

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

31742 - прямой вызов
32637 - direct
34128 - queue

Это затраченное время в мс на 1000000 итераций.

Это не совсем корректно.
Лучше делать замеры между вызовом emit signal и непосредственным вызовом slot'а.

Да, понял ошибку. Но лень сейчас накидывать тест.

[Пантер]

Вопщем, я к тому, что у DirectConnection будет незначительная просадка, по отношению к прямому вызову. QueueConnection будет значительно им уступать, но тут  все логично.

[xokc]

Если речь идет об одном потоке писателе и одном читателе - тут всё понятно. Интереснее вопрос насколько успешно система сигнал/слотов разрулит ситуацию с несколькими (многими) писателями и несколькими (многими) читателями. А также то, насколько она в этом смысле эффективнее (или не эффективнее), например, очереди на QAtomic или неблокирующей очереди из liblfds.org. Или очереди на ZeroMQ. И так далее.

[qate]

А также то, насколько она в этом смысле эффективнее (или не эффективнее), например, очереди на QAtomic или неблокирующей очереди из liblfds.org. Или очереди на ZeroMQ. И так далее.

чтобы внедрять "другие" очереди в проект на qt - это надо действительно иметь причину (не баг) для этого
о таких случаях я нигде не читал (не говорю что читал многое)

[vulko]

Если речь идет об одном потоке писателе и одном читателе - тут всё понятно. Интереснее вопрос насколько успешно система сигнал/слотов разрулит ситуацию с несколькими (многими) писателями и несколькими (многими) читателями. А также то, насколько она в этом смысле эффективнее (или не эффективнее), например, очереди на QAtomic или неблокирующей очереди из liblfds.org. Или очереди на ZeroMQ. И так далее.

Сигнал-слоты это не производительное решение, т.к. queuedconnection не подразумевает быстрого отклика, а direct connection вообще не подходит для многопоточного использования.
В этом контексте мне непонятно о какой эффективности ты говоришь.

[vulko]

Вопщем, я к тому, что у DirectConnection будет незначительная просадка, по отношению к прямому вызову. QueueConnection будет значительно им уступать, но тут  все логично.

Именно. При этом direct и queued connection'ы - это абсолютно разные вещи. Один для однопотока, второй для многопотока.

[Igors]

По поводу измерений. "Давайте вызовем мульен напрямую а потом мульен слот-сигнал, вот и все". Это не годится для queued. Непрерывно помещая сигнал (фактически событие) в очередь, мы постоянно/часто блокируем мутекс очереди, и обработчику трудно извлечь событие. В результате увидим гораздо больший оверхед, который сами же и создали. Поэтому посылается то число сигналов которое обработчик может переварить (получено прямым вызовом), и не все сразу а равномерно (порциями).

Тут одна неточность - для queued меряем только время приема, но ведь есть еще и посылка (которая сейчас в др нитке/ядре)

Как этим пользоваться. Запустить и посмотреть оверхед queued c небольшой нагрузкой. Напр вижу он не больше 10%, меня устраивает. Если нет - подкрутить константу NUM_STR (нагрузка больше/меньше). Имеем число обработок в секунду, напр 20K. Это можно считать пропускной способностью очереди, (немного завышенной). Т.е. если мы будем шмалять такие сигналы с частотой 20К/sec, то очередь будет расти и, возможно, переполнится. А вот если  10K (или даже 15K) то нам ничего не грозит, и затраты на слот/сигнал не превышают 10% от полезной работы.

Теперь осталось засечь число срабатываний слота в проекте. Пример (с которого все началось). Человек спросил какие проблемы могут быть если на частоте сотни в секунду в теле слота выполняется помещение а контейнер. Эту операцию нет смысла даже мерять - "холостой ход". Да, 90% оверхед, или даже больше. Но при такой ничтожной частоте и потери-то с гулькин нос. Т.е. затратили напр 1 секунду (за неск часов работы приложения). Мы могли сделать то же за 0.1 секунды (в 10 раз быстрее), но зачем?

Если речь идет об одном потоке писателе и одном читателе - тут всё понятно. Интереснее вопрос насколько успешно система сигнал/слотов разрулит ситуацию с несколькими (многими) писателями и несколькими (многими) читателями. А также то, насколько она в этом смысле эффективнее (или не эффективнее), например, очереди на QAtomic или неблокирующей очереди из liblfds.org. Или очереди на ZeroMQ. И так далее.

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

а если завести 4 qeventloop-a и в каждом бросать сигналы и ловить слоты - может ядра загрузятся ?

У каждой нитки свой (и только один) qeventloop, поэтому не вижу как создать ситуацию "много читателей" (из того же ведра). "Много писателей" - см последний тест, да, пагубно влияет.

если гдето ответят - отпишись тут )

Да я, собственно, ничего и не спрашивал