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

Question

В поисках ответов здесь для «сродства к потоку» я вижу большой интерес к этому, но мало оправданий для этого, кроме возможного получения стабильных результатов QueryPerformanceTimer.

Если предположить, что у вас есть современная ОС и современная машина класса рабочих станций / серверов с 2–4 сокетами и современными 4–6-ядерными процессорами, у кого есть веские основания полагать, что они знают лучше, чем планировщик своей ОС? Существуют ли ситуации в реальном мире, когда лучше взять контроль над близостью? Какие преимущества в производительности можно продемонстрировать?

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

Answer 1

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

Answer 2

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

Answer 3

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

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

Answer 4

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

Answer 5

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

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

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

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