Вопрос о приложении с несколькими потоками на нескольких CPU-машинах

Question

Дана машина с 1 процессором и большим количеством оперативной памяти. Помимо других видов приложений (веб-сервер и т. Д.), На этом компьютере работают 2 других серверных приложения, выполняющих точно такую ​​же обработку, хотя одно использует 10 потоков, а другое - 1 поток. Предположим, что логика обработки каждого запроса на 100% связана с ЦП и обычно занимает не более 2 секунд. Вопрос в том, чья пропускная способность с точки зрения транзакций, обрабатываемых за минуту, может быть лучше? Почему?

Обратите внимание, что вышеизложенное не является реальной средой, я просто собираю данные, чтобы прояснить вопрос. В настоящее время я думаю, что не должно быть никакой разницы, потому что приложения на 100% связаны с процессором, и поэтому, если машина может обрабатывать 30 запросов в минуту для второго приложения, она также сможет обрабатывать 3 запроса в минуту для каждого из 10 потоков 1-го приложения. Но я рад, что оказался неправ, учитывая тот факт, что на машине запущены другие приложения, и одному приложению не всегда может быть предоставлено 100% процессорного времени.

Answer 1

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

С другой стороны, разница не может быть измеримой.

Answer 2

Интересный вопрос.

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

Я запустил это на одной виртуальной машине с процессами, так как больше не мог найти настоящий компьютер с одним процессором.

Запустить самостоятельно:

1 Thread    5000 Work Units - 50.4365sec
10 Threads  5000 Work Units - 49.7762sec

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

Бежать вместе (или как можно ближе к нажатию клавиши ввода одновременно):

1 Thread    5000 Work Units - 99.5112sec
10 Threads  5000 Work Units - 56.8777sec

Это суть вопроса. Когда вы запускаете 10 потоков + 1 поток, кажется, что все они запланированы одинаково. Каждый из 10 потоков занимал 1/10 дольше (потому что был запущен одиннадцатый поток), в то время как другой поток занимал почти вдвое больше времени (в действительности, он выполнял 1/10 своей работы за первые 56 секунд, а затем остальные 9 /). 10-е в следующие 43сек ... что примерно так).

Результат: планировщик Window работает на уровне потока, но не на уровне процесса. Если вы создаете много потоков, вы можете оставить другие процессы, которые были недостаточно умными, чтобы сделать много потоков высокими и сухими. Или просто сделайте это правильно и используйте пул потоков: -)

Если вы хотите попробовать это сами, вы можете найти мой код: http://teeks99.com/ThreadWorkTest.zip

Answer 3

Это вполне может зависеть от планировщика операционной системы. Например, в однопотоковые дни планировщик знал только о процессах и имел такие меры, как «благородство», чтобы выяснить, сколько выделять.

В многопоточном коде, вероятно, существует способ, при котором один процесс, имеющий 100 потоков, не получает 99% процессорного времени, если есть другой процесс, имеющий один поток. С другой стороны, если у вас есть только два процесса, и один из них является многопоточным, я подозреваю, что ОС может дать ему больше общего времени. Тем не менее, AFAIK ничего не гарантировано.

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

Answer 4

Планирование может сделать приложение с 10 потоками медленнее, чем приложение с 1 потоком Вы не будете знать наверняка, если не создадите тест.

Некоторые сведения о многопоточности см. http://en.wikipedia.org/wiki/Thread_(computer_science)

.

Answer 5

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

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