Если итак шедулер где все спят на мьютексе в очереди почему бы не снизить контеншен

Так если спят из-за шедулера

Тут сначала с ним надо разобраться

А потом странд можно попытаться использовать

Там на самом деле часть планировщика уже делает work-stealing в локфри виде. И это немного помогает. Но пока это только для частных случаев работает

нет

он декорирует так что ему все равно где и на ком исполнят задачи

Хм...

https://paste.ubuntu.com/p/N8Sjr566DC/ игрушечный

Ну может и сработает, надо по специфике задач смотреть

Мы не знаем будущей работы, поэтому не можем ее линеаризовать предварительно. Пользователь ведёт кистью, мы генерим части штриха сколько можем, потом по таймеру 1/60сек обрубаем, ставим барьер и начинаем это все собирать вместе и показывать пользователю. Сколько успели просчитать, столько и будем сливать вместе

Вроде в Бусте есть текстовое описание. Завтра посмотрю, спасибо :)

Кстати, на сложных задачах, где физических тасков мало и они длинные, вроде гауссиан-фильтра у нас масштабируемость по ядрам почти полная. Как раз благодаря тому, что само хранилище локфри.

Вот тут мы писали про эти проблемы когда-то (осторожно, много маркетинга, но зато в конце красивые графики):
https://software.intel.com/content/www/us/en/develop/articles/enhancing-user-experience-krita-application-utilizing-multiple-cores-on-intel-architecture.html

Звучит как плохие задачи(слишком мелкие, < 100ns, и планировщик слишком заметен относительно или слишком крупные, то есть планировщик голодает)/плохой планировщик.

Вообще кажется в плане планирования небольших задач(~10us) все пришли к примерно одному решению golang, kotlin, rust везде планировщик это глобальная очередь с мьютексом и локальные для потока spsc.
С некоторыми оптимизациями и страшным кодом.

А для больших задач кажется важнее скорее честность распределения, и учитывая то что больших задач не будет много, этот оверхед не будет заметен, и кажется любая очередь + мьютекс подойдёт

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

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

Вообще во всех этих тредпулах, самое неприятное как по мне это научить потоки нормально спать и просыпаться, особенно когда мы что то локфри пишем

Зачем добавлять в очередь те задачи которые ещё не готовы исполнятся? То есть колбеки, верно? Или это попытка жить без корутин/файберов, и исполнять что то полезное во время ожидания функторов?

Колбеков там нет. Там семантика вроде: когда все эти параллельные задачи закончатся, запусти вот эту группу параллельных задач, которая будет обрабатывать результат предыдущей.

Issue 2 звучит странно, может я не так перевел конечно. Что значит задачи слишком малы и поток уходит в сон? Как батчинг в таком случае поможет? Задач в очереди станет ещё меньше.
Бтв qthreadpool это же просто какая то очередь + мьютекс, то есть идеальное распределение задач и неясно как там может возникать ситуация, когда задачи были запушены в тредпул, а поток тредпула их не видит.

Ну выглядит как типичный
whenAll(Async()
Async()
Async()).then(
...)