Почему значение max_workers по умолчанию для ThreadPoolExecutor определяется на основе количества процессоров?

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

Кроме того, добавление значения по умолчанию было довольно мало усилий, малое обсуждение изменение. (Раньше не было значения по умолчанию).

Тем не менее, становление более привлекательным может окупиться. Может быть, какая-то динамическая система, которая регулирует количество потоков в зависимости от нагрузки, поэтому вам не нужно определять количество в то время, когда у вас меньше всего информации. Однако этого не произойдет, если кто-то не напишет это.

Реализация потока CPython очень легкая. В основном он отправляет это в ОС с некоторым учетом GIL (и сигнала умение обращаться). Увеличить количество потоков пропорционально ядрам обычно не получается. Поскольку потоки управляются операционной системой со многими ядрами, ОС становится жадной и пытается запустить как можно больше готовых потоков, если есть переключение контекста потока. Все они пытаются заполучить GIL, и только одному это удается. Это приводит к большому количеству потерь — хуже, чем линейный расчет, предполагающий, что в данный момент времени может выполняться только один поток. Если вы используете чистые потоки, привязанные к процессору, в исполнителе, нет причин связывать его с ядрами из-за этого. Но мы не должны лишать пользователей, которым действительно нужна мощность процессора и которые согласны с выпуском GIL для использования ядер. Таким образом, возможно, в этом случае значение по умолчанию должно быть связано с количеством ядер - если вы предполагаете, что большинство людей, использующих Python, знают, что они делают.

Теперь, если потоки в исполнителе связаны с вводом-выводом, то вы правильно упомянули, что максимальная мощность составляет 1/p, где p — это доля ЦП, необходимая каждому потоку. Для определения значения по умолчанию невозможно заранее узнать, что такое р. Минимум по умолчанию 0,2 (минимум 5 потоков) выглядит не так уж плохо. Но обычно я предполагаю, что это p будет намного ниже, поэтому ограничивающим фактором никогда не может быть ЦП (но если это так, мы снова сталкиваемся с проблемой перегрузки ЦП из-за нескольких ядер, как указано выше). Таким образом, привязка к количеству ядер, вероятно, не окажется небезопасной (если только потоки не имеют интенсивной обработки или у вас слишком много ядер!).