Потоки против ядер, когда потоки спят

Как уже упоминалось в комментариях, это зависит от ряда факторов. Но в целом ваши предположения верны.

Спать

В старые добрые времена sleep() могла быть реализована библиотекой C как цикл, выполняющий бессмысленную работу (например, умножение 1 на 1, пока не истечет требуемое время). В этом случае ЦП все равно будет загружен на 100%. В настоящее время sleep() на самом деле приводит к тому, что обсуждение переносится на необходимое время. Такие платформы, как MS-DOS, работали таким образом, но любая многозадачная ОС имела надлежащую реализацию на протяжении десятилетий.

10 000 спящих потоков займут больше процессорного времени, потому что ОС должна принимать решения о планировании каждый тик временного интервала (каждые 60 мс или около того). Чем больше потоков нужно проверить на готовность к запуску, тем больше процессорного времени займет проверка.

Перевод резервных буферов

Добавление большего количества потоков, чем ядер, обычно рассматривается как нормальное явление. Но вы можете столкнуться с проблемой с Translate Lookaside Buffers (или их эквивалентами на других процессорах). Они являются частью управления виртуальной памятью ЦП и сами по себе являются адресной памятью содержимого. Это действительно сложно реализовать, поэтому этого никогда не бывает так много. Таким образом, чем больше выделений памяти (что будет, если вы будете добавлять все больше и больше потоков), тем больше этот ресурс съедается до такой степени, что ОС, возможно, придется начать подкачку различных загрузок TLB для того, чтобы все выделения виртуальной памяти должны быть доступны. Если это начинает происходить, все в процессе становится очень, очень медленным. Вероятно, в наши дни это менее проблематично, чем, скажем, 20 лет назад.

Кроме того, современные распределители памяти в библиотеках C (и, следовательно, все остальное, созданное поверх них, например, Java, C# и т. д.) на самом деле будут весьма осторожны в том, как обрабатываются запросы на виртуальную память, сводя к минимуму время, которое они фактически должны выполнять в качестве операционной системы. больше виртуальной памяти. По сути, они стремятся предоставить запрошенные распределения из пулов, которые у них уже есть, а не каждое malloc(), приводящее к вызову ОС. Это принимает на себя давление TLB.

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

Есть несколько факторов, которые мог заставляют поведение отклоняться от «идеального».

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

2. Существуют различные накладные расходы, связанные с ядром операционной системы. Есть много мест, где это происходит, в том числе:

   • Управление файловой системой.
   • Управление системой физической/виртуальной памяти.
   • Работа с сетевым трафиком.
   • Планирование процессов и потоков.

   Это уменьшит ЦП, доступный для вашего приложения.

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

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

Так:

1) If I have CPU with 10 cores, and I spawn 10 threads, each thread will have its own core and run simultaneously.

Вероятно, не всегда, из-за других пользовательских процессов и накладных расходов ОС.

2) If I launch 20 threads with a CPU that has 10 cores, then the 20 threads will "task switch" between the 10 cores, giving each thread approximately 50% of the CPU time per core.

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

3) If I have 20 threads but 10 of the threads are asleep, and 10 are active, then the 10 active threads will run at 100% of the CPU time on the 10 cores.

Примерно: см. выше.

4) An thread that is asleep only costs memory, and not CPU time. While the thread is still asleep. For example 10,000 threads that are all asleep uses the same amount of CPU as 1 thread asleep.

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

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

5) In general if you have a series of threads that sleep frequently while working on a parallel process. You can add more threads then there are cores until get to a state where all the cores are busy 100% of the time.

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

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

1. Сохраните регистры старого потока.
2. Очистите кеш памяти процессора
3. Сделайте недействительными регистры сопоставления виртуальных машин и т. д. Сюда входят TLB, упомянутые @bazza.
4. Загрузите регистры нового потока.
5. Примите удары по производительности из-за необходимости выполнять больше операций чтения основной памяти и переводов страниц виртуальных машин из-за предыдущих аннулирования кеша.

Эти накладные расходы могут быть значительными. Согласно https://unix.stackexchange.com/questions/506564/ это обычно составляет около 1,2 микросекунды на переключение контекста. Это может звучать немного, но если ваше приложение быстро переключает потоки, это может составлять много миллисекунд в секунду.