Каковы веские причины в наши дни устанавливать сходство потоков, а не оставлять это на усмотрение ОС?

Основная причина в том, что у вас есть что-то, что сильно зависит от кэширования. Планировщик ОС не обязательно учитывает это в той степени, в которой вам хотелось бы.

Я использую его для назначения потоков ядрам; например, в симуляции вы полностью выполняете физику на одном ядре и позволяете выполнять остальные вычисления на другом. Имеет смысл иметь возможность контролировать это, если вы находитесь в жесткой среде, где вы знаете аппаратное обеспечение.

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

В ядре ОС и иногда в драйверах режима ядра вам необходимо выполнить одно и то же действие на каждом процессоре (например, обновить системный регистр). Вы можете сделать это в цикле в одном потоке, изменяя сходство на каждой итерации.

Для настольных компьютеров это совершенно не нужно.

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

Другая возможность: у вас есть критическая задача — вы выделяете ей весь ЦП, а остальные задачи используют остальные ЦП.

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

Я бы согласился, что в большинстве ситуаций лучше оставить процессору, чтобы он разобрался с этим. Тем не менее, насколько я видел, наиболее распространенная причина для привязки потоков — это когда вам нужна хорошая зависимость от кеша. В системах с несколькими ЦП, когда конкретный ЦП кэширует что-то индивидуально для себя, и если то же самое было кэшировано в каком-то другом ЦП, я полагаю, что это может автоматически стать недействительным на другом ЦП. Таким образом, если конкретный поток продолжает менять процессоры, на которых он выполняется, то частота попаданий в кэш будет слишком низкой. Так что в этом случае, я думаю, программисту имеет смысл лучше разбираться в сходствах COU. Я также думаю, что приведенное выше замечание Ариэля о том, что критическая задача постоянно получает процессор, не ограничивая другие процессы с низким приоритетом, также имеет смысл.