#многопоточность
Где n - количество физических ядер. Не раз уже встречаю это правило, но никак не
могу понять зачем так делать и всегда ли оно эффективнее создания n потоков.
Ответы
Ответ 1
но никак не могу понять зачем так делать Как правило, программы "общего назначения", кроме, собственно, расчетов выполняют операции ввода-вывода (диск, сеть, прочие устройства). На время ожидания медленных операций ядро неплохо бы загрузить полезной работой. Поэтому добавляют +1. Почему +1 а не более? Сейчас не найду - но помню точно, видел бэйнчмарки для make -jN. Практически везде выигрывала комбинация +1. Таким образом, устоявшаяся практика - имеет чисто экспериментальную аргументацию. и всегда ли оно эффективнее создания n потоков Не всегда. Если процессы заняты исключительно пересчетами, и доля I/O-операций ничтожно мала - добавление "дополнительного" потока суммарной скорости не прибавит. Более того, возможно скорость незначительно упадет.Ответ 2
Насколько мне известно, такая рекомендация возникла из соображений максимальной утилизации вычислительной мощности. Предполагается, что поток может выполнять какие-либо операции ввода-вывода (диск, сеть, память), требующие большого времени ожидания, в течении которого поток не загружает ядро процессора на 100%. Поэтому создаётся дополнительный n+1-й поток, который в это время и использует "простаивающие" мощности. P.S. Рекомендация не моя и спорить по её поводу я не буду. ;-)Ответ 3
Рекомендация N+1 применима только для систем, которые обрабатывают поток неравномерных задач, с частыми, но короткими прерываниями на IO. Типичный пример - make -jN, который тут уже упоминали. В нем "дополнительный" поток позволяет заполнить простои CPU, вызванные IO. Для систем, обрабатывающих заведомо одинаковые длинные задачи, CPU-bound, без IO - выгоднее выставление количества задач в N + использование affinity - привязки потока к конкретному ядру. Самый верный способ узнать, сколько потоков лучше использовать для конкретной задачи - взять и померять.
Комментариев нет:
Отправить комментарий