К вопросу об организации взаимодействия пула производителей и одного потребителя

[Авварон]

Ну шаред_птр можно использовать для повторного исполнения одной таски (аналог убого QRunnnable::autoDelete)

[Igors]

Возможно классическая очередь здесь не является лучшим решением. Ну конечно с "хорошим" кластером все будет норм, но если он противно мал, напр порядка 10 ms? (это навскидку, крытычное время может быть совсем иным).

Вообще "многопоточностью" занимаются/владеют все, но ни разу не видел замеров КПД. Интересно было бы проверить, напр на одной нитке 1000 задач выполняется за 10 сек. Сколько будет считаться на 4 нитках? Др словами каковы накладные расходы или насколько время больше идеального 2.5 сек ?

Лучшее решение думается есть  

[m_ax]

Возможно классическая очередь здесь не является лучшим решением. Ну конечно с "хорошим" кластером все будет норм, но если он противно мал, напр порядка 10 ms? (это навскидку, крытычное время может быть совсем иным).

У меня на 8 ядрах, моя задача с последней реализацией thread_poolа примерно в 6 раз стала быстрее. И это только пока на "игрушечных" данных.   В реальной ситуации время расчётов там до нескольких часов может легко составить и там, по-видимому, выйгрыш будет стремиться к 8.

Интересно было бы проверить, напр на одной нитке 1000 задач выполняется за 10 сек. Сколько будет считаться на 4 нитках? Др словами каковы накладные расходы или насколько время больше идеального 2.5 сек ?

Зависит от криворукости того, кто будет параллелить) И от самой задачи: может она в принципе не распараллеливается.. Тогда только пройгрыш будет..

[Авварон]

Вообще "многопоточностью" занимаются/владеют все, но ни разу не видел замеров КПД. Интересно было бы проверить, напр на одной нитке 1000 задач выполняется за 10 сек. Сколько будет считаться на 4 нитках? Др словами каковы накладные расходы или насколько время больше идеального 2.5 сек ?

Лучшее решение думается есть  

Самое смешное, что на нескольких нитках прирост может быть весьма большой. Гораздо интереснее, как ведет себя приложение на большом количестве ниток (16, 32). Например, не так давно было сравнение qbs и сmake и ВНЕЗАПНО оба деградируют начиная с какого-то значения - сколько бы ниток дополнительных мы бы не насыпали, общее время сборки не уменьшается.
А так, то, что вы не видели замеров КПД, не означает, что их не делают. Вот, например, сравнение стеков (lock-free и нет) (всё из того же цикла статей что вы не осилили ). А вот очереди.

[Igors]

А так, то, что вы не видели замеров КПД, не означает, что их не делают. Вот, например, сравнение стеков (lock-free и нет) (всё из того же цикла статей что вы не осилили ). А вот очереди.

Я имел ввиду "ни разу не видел замеров КПД на этом форуме", напр Ваших

Пару месяцев назад был интересный случай. Я знал что это место "не масштабится", ну так и оказалось с QThreadPool - скорость та же что и на 1 нитке. Ну думаю, ладно, реализация не накладная, пусть так и остается. А у заказчика 32 ядра, хирак - вдвое МЕДЛЕННЕЕ чем на одной. Не могу объяснить почему.

[Old]

Я знал что это место "не масштабится", ну так и оказалось с QThreadPool - скорость та же что и на 1 нитке.

То есть вы знали что это место "не масштабится", но каким то образом его распаралелили?  Или оно все же масштабируется, но у вас не получилось?

Не могу объяснить почему.

Ну так вы бы показали, что вы там "распаралелили", и получите ответ.

[m_ax]

В реальной ситуации время расчётов там до нескольких часов может легко составить и там, по-видимому, выйгрыш будет стремиться к 8.

Прибавил немного нагрузку, и, как предпологал, выйгрыш в производительности медленно пополз вверх)
В однопоточном варианте алгоритма время составило t = 7919 sec, а на 8 ядрах t = 1210 sec. Т.е. в 6.54 раза быстрее получается с пулом)
Издержки в основном связаны с тем, что есть общие данные, которые нужно лочить..

В общем я доволен    

[Igors]

Есть хороший метод который я стал забывать (наверно тлетворное влияние этого форума). Когда стандартное решение проходит, полезно поискать - а чем данная задача отличается от стандартной? Это такие "мелкие детали" которые, на первый взгляд, ничего не меняют. Но если присмотреться, то нередко получаются велики которые не только полезны для понимания, но и объективно являются лучшим решением. Попробуем применить к данному случаю.

По классике воркер извлекает задачу из очереди под защитой мутекса. Все верно, ведь в общем случае очередь может пополняться другими, поэтому надо брать мутекс. Но в данном случае пополнения-то нет. Поэтому задачу можно и не извлекать, а просто застолбить ее индекс (легко делается атомиком). И мутекс воркеру нужен только для того чтобы заснуть когда нет больше задач. Последнее тоже спорно, но не все сразу.

Основная сложность - трудновато заставить себя вернуться к тому что "уже работает" - и вроде хорошо 

[Old]

По классике воркер извлекает задачу из очереди под защитой мутекса. Все верно, ведь в общем случае очередь может пополняться другими, поэтому надо брать мутекс. Но в данном случае пополнения-то нет. Поэтому задачу можно и не извлекать, а просто застолбить ее индекс (легко делается атомиком). И мутекс воркеру нужен только для того чтобы заснуть когда нет больше задач. Последнее тоже спорно, но не все сразу.

А потом:

А у заказчика 32 ядра, хирак - вдвое МЕДЛЕННЕЕ чем на одной. Не могу объяснить почему.

))

[m_ax]

Поэтому задачу можно и не извлекать, а просто застолбить ее индекс (легко делается атомиком). И мутекс воркеру нужен только для того чтобы заснуть когда нет больше задач. Последнее тоже спорно, но не все сразу.

Вообще говоря, это проблема из области теории игр https://www.youtube.com/watch?v=zypuneus6b0.. И в данном контексте она легко моделируется..
Я не вижу здесь каких то нетривиальных затруднений, чтоб сообразить как нужно рационально воспользоваться thread_pool или concurrent_loop..

[Igors]

Вообще говоря, это проблема из области теории игр https://www.youtube.com/watch?v=zypuneus6b0.. И в данном контексте она легко моделируется..

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

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

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

[m_ax]

Не вижу здесь никакой связи с теорией игр.

Связь прямая. Это типично игровая ситуация, когда нужно организовать работу воркеров так, чтоб минимизировать их стояние (толкучку) в очереди за задачами.

что вообще осталось в голове студента после таких лекций? Да ничего.

Это не студенты - это открытая лекция. Вот У Вас, видимо ничего не останется)
Я своим студентам тоже даю задачку смоделировать на плюсах жизненную ситуацию из теорию игр) И они в восторге обычно после этого остаются)

Ну ладно, не надо - так не надо  

Давайте обсудим Вашу реализацию на атомиках и сравним (Для чистоты эксперимента лучше дать реализацию с STL)


ЗЫ Задачка: На ФизФаке 6 лифтов. Этажей 14. Время подъёма лифта на один этаж t1. Если лифт останавливается на каком-либо этаже, мы ждём пока двери откроются, кто-то выйдет и двери закроются - это время ожидания t2. Вопрос: как организовать работу лифтов так, чтобы минимизировать время развоза всех N студентов с первого этажа по их  этажам. Никто из N студентов не знает кому из других студентов на какой этаж нужно.  Времена t1 и t2 мы менять не можем.

ЗЗЫ Да, студены уже заранее знают ответ, поскольку на ФизФаке это уже реализовано) Но интересно колличественно сравнить)

[Igors]

Связь прямая. Это типично игровая ситуация, когда нужно организовать работу воркеров так, чтоб минимизировать их стояние (толкучку) в очереди за задачами.

Это уже совсем другая задача которая требует доп данных, напр примерное/ожидаемое время выполнения каждой.

Давайте обсудим Вашу реализацию на атомиках и сравним

Уменьшайте нагрузку до тех пор пока КПД не упадет, напр на 4 нитках быстрее всего в полтора раза, а не в 4 как хотелось. Собсно интересно каким окажется это время. А я исполню на атомиках.

ЗЫ Задачка: На ФизФаке 6 лифтов. Этажей 14. Время подъёма лифта на один этаж t1. Если лифт останавливается на каком-либо этаже, мы ждём пока двери откроются, кто-то выйдет и двери закроются - это время ожидания t2. Вопрос: как организовать работу лифтов так, чтобы минимизировать время развоза всех N студентов с первого этажа по их  этажам. Никто из N студентов не знает кому из других студентов на какой этаж нужно.  Времена t1 и t2 мы менять не можем.

ЗЗЫ Да, студены уже заранее знают ответ, поскольку на ФизФаке это уже реализовано) Но интересно колличественно сравнить)

Не понял чем тут "манипулировать" (что менять). Наверное какой лифт куда развозит? (до какого этажа).

[m_ax]

Не понял чем тут "манипулировать" (что менять). Наверное какой лифт куда развозит? (до какого этажа).

Вы главный лифтёр и можете программировать их работу как хотите. Но времена t1 и t2 менять не можете (причём обычно t2 > t1). И ещё вы знаете, что в фае (на первом этаже) никто из N cтудентов на знает кому другому на какой этаж нужно) Ваши действия?

[m_ax]

Это уже совсем другая задача которая требует доп данных, напр примерное/ожидаемое время выполнения каждой.

Нет, я бы не сказал.. Есть задачи, которые можно эффективно распараллелить (если они в принципе параллелются), не интересуясь временем исполнения одной таски..