А как вы ожидаете тогда их?
Ну то есть в варианте выше, после исполнения каждого async, уменьшается какой-то аторманый счётчик например. И когда он достигает нуля в нужный тредпул пушится колбек переданный в then.
То есть код пуша исполняет последний async в тред пуле => когда тредпул завершит async-и эта задача точно там будет.

Для этого там планировщик и есть. В очереди куча задач, у задач есть метаданные. В задаче может быть указано "дождись всех вот этих", он ждёт.

Когда какая-либо задача завершается, поток идет в общую очередь и спрашивает, есть ли что ещё поделать. Сама очередь под мьютексом, поэтому, если задачи слишком мелкие, они начинают на этом мьютексе спать.

Мьютекс вероятно берется на 10ки инструкций, в духе достань эту ноду из интрузив листа, почему задачи спят на мьютексе, любая разумная реализация мьютекса и pthread в том числе будет сначала крутится. Понятно что может не везти из-за планировщика оси, но кажется маловероятным при размере тредпула ~ количество ядер * ht

Зачем ждать задачи, если таска хочет их дождаться, почему не заниматься чем то полезным, например их исполнением?
Колбек как раз решает эту проблему, задача будет запущена, когда будут исполнены все необходимые для нее задачи. При этом ожидание будет в другом месте, там где вы ждёте итоговый результат, и это вероятно должен быть не тредпул.
Это можно решать через явные граф задач, но неясно зачем

Да, там сотни инструкций, т.к. он в том числе проверяет, что конкретно можно запустить в этот момент.

Насчёт колбэков надо подумать, хотя я не уверен, что это возможно. Там ещё бывает так, что задачи добавляются посреди очереди, откладывая хвост очереди на будущее (когда вдруг поняли, что пора пользователю следующий кадр показывать). Т.е. нормальный граф заранее там особо не построишь.

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

Там сами задачи могут не знать всего контекста. Например, в очереди десяток задач, каждая из которых работает с какой-то областью изображения. Эти области пересекаются (обычно из-за наличия сверточных фильтров). Задача планировщика обеспечить, чтобы параллельно работали только задачи с непересекающимися областями.

А регионы фиксированные? В духе побьем изображение на 10 тайлов и для каждой задачи известно с каким набором тайлов она хочет работать?

Фиксируется при создании задачи, а так произвольные

Занятно, а у вас там к чему более ближе ситуация к реальному времени или к большим данным? Ну т. е. мне видится, что второе, а может лучше задержки увеличить и кормить большим объёмом данных потоки?

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

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

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

Ага, понятно, тогда точно делайте как предполагалось выше про геймдев, длина кадра фиксированная и известная, не важно что там в планировщике, он вам понадобится только для финального рендеринга при экспорте, а в основном, в процессе редактирования, вам проще к кадрам привязываться

Ну т. е. рендер исключительно в одном потоке или пуле (кусочками области), обработка диффа изменений и всё планирование в другом. Кстати, а вас GPU используется, потому что очень похоже что было бы проще на GPU всё делать...

GPU очень хочется, но колется :) Для этого придется все ядро на него переписать, а это больно очень. По частям смысла нет, так как большинство операций (с помощью SSE/AVX) работают на скорости 3-6 memcpy, так что трансфер данных на GPU и обратно съест весь выигрыш.

Это да, крупный рефакторинг нужен, но оно того точно стоит. Это и энергоэффективно, да и мощность у GPU растёт быстрее чем у CPU, плюсом идут аппаратные реализации очень большого количества моментов в рендеринге, в т. ч. уже и сложной физики воды и света

Ну вот мы на это пока только в бэкграунде как-то смотрим :)

Надо pipeline вычислений размещать на gpu  без пративного cpu

Там же ещё будет три реализации этого движка. Одна для куды, вторая для oneapi, третья для полумертвого opencl :)

И вся эта радость ещё на четырех ОС :)