Преимущество настройки потоков для работы на конкретном ядре? - PullRequest
2 голосов
/ 27 мая 2009

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

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

Ответы [ 2 ]

1 голос
/ 27 мая 2009

Я не вижу, что для этого есть причина.

Помните, что любая многопроцессорная ОС автоматически распределяет процессорное время по своему усмотрению при попытке сбалансировать загрузку процессора.

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

Если вы исправили выполнение кода процесса только на одном указанном процессоре, это, скорее всего, снизит его производительность, поскольку не позволит ОС сбалансировать загрузку процессора.

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

0 голосов
/ 27 мая 2009

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

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

...