сколько ядер я должен использовать для расчетов? #cores или #cores -1?


12

У меня есть большой расчет, чтобы сделать. Хотя я могу использовать все ядра, я подумал, есть ли какая-то причина, чтобы оставить 1 ядро ​​и не использовать его? (расчетный процессор только без ввода-вывода). Или я недооцениваю ОС, которую она не знает, чтобы справиться и правильно переключить контекст, даже если я использую все ядра?


8
Использование всех ядер - хорошее начало, и некоторые суеверия о том, что ОС ведет себя лучше с «-1 ядром», вероятно, просто - суеверие, но вы должны на самом деле профилировать его, как оно ведет себя для ваших расчетов, вашего оборудования, вашей операционной системы.
Док Браун

Во многих случаях использование # cores + 1 имеет большой смысл. Если вы просто используете #cores, то любое неожиданное блокирование (например, сбой страницы) без необходимости заставляет ядро ​​бездействовать.
Дэвид Шварц

Ответы:


28

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

Выбор количества ядер зависит больше от вашего намерения сделать что-то еще во время выполнения расчета.

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

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


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

Примечание: даже на серверах, если вы хотите иметь возможность ssh и получить быстрый ответ, полезно оставить ядро ​​0 в покое.
Матье М.

11

По-разному.

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

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

Если машина не предназначена для вычислений, предоставление 100% вычислений может быть не идеальным. Например, если вы используете веб-браузер во время вычислений. Поскольку нагрузка на вашу машину иногда достигает пика выше 100%, она будет вялой. Задачи, ориентированные на пропускную способность, такие как вычисления, на самом деле не будут замедляться, но чувствительные к задержкам задачи, такие как GUI, не будут реагировать так быстро. Тогда имеет смысл запускать только потоки / процессы NPROC-1 для вычислений. В качестве альтернативы, явное использование более низкого приоритета для вычислений, чем для обычных задач, могло бы решить эту проблему, и в этом случае вычисления должны использовать процессы NPROC, чтобы не тратить какие-либо ресурсы.


3
«если вы используете веб-браузер, когда вычисления выполняются […], это будет замедляться. Задачи, ориентированные на пропускную способность, такие как вычисления, не будут замедляться, но задачи, чувствительные к задержкам, такие как GUI, не будут реагировать так быстро. [ …] Явное использование более низкого приоритета для вычислений, чем для обычных задач, могло бы решить эту проблему »- и именно поэтому значение приоритета процесса в Unix называется« правильностью »и настраивается с помощью утилиты с именем nice.
Йорг Миттаг

2
«Неиспользованные вычислительные ресурсы не ускоряют работу» технически, они могли бы. Использование меньшего количества ядер может позволить более высокую тактовую частоту и уменьшить синхронизацию, что может ускорить или не ускорить процесс.
Davidmh

2
В дополнение к @Davidmh заметки, как правило, на стороне процессора, L1 $ и L2 $ в некоторой степени распределяются между потоками, а L3 $ распределяется по всему сокету, поэтому использование большего количества потоков может привести к увеличению пропусков $, что замедляет процессы. Особенно, если процесс связан с памятью, а не с процессором.
Maciej Piechotka

Если вы правильно установили уровни приоритетов потоков / процессов, вы можете смягчить влияние фоновой работы на интерактивные процессы. Я использую распределенные вычислительные приложения на своем персональном компьютере более десяти лет; и с задачами вычисления ЦП, работающими с низким приоритетом, моя способность использовать браузеры и другие обычные приложения для настольных компьютеров не ухудшается. Совместное использование ресурсов на графическом процессоре не так продвинуто, и я иногда сталкивался с проблемами с HTML5-видео с ускорением на GPU (не говоря уже об играх), когда выполнялись вычисления на GPU в фоновом режиме. Многопоточные игры могут быть проблематичными даже с легким GFX; победа умирает от темы 2+
Дэн возится с Firelight

1

Я немного осмотрительно согласен с @motoDrizzt, ниже, из-за его отрицательных голосов :), но это действительно был мой реальный опыт - чем больше, тем лучше, даже помимо фактического количества ядер (но не тысяч). Например, взгляните на http://www.forkosh.com/images/avoronoi.gif, где каждая 2D-плоскость этой 3D-voronoi_diagram может быть сгенерирована независимо. И программа берет атрибут nfork = n query_string, чтобы раскошелиться на вычисления для n плоскостей "одновременно".

В случае с четырехъядерным процессором время (пользователь) для завершения диаграммы линейно уменьшается с nfork, примерно до nfork = 8 (гиперядь с четырьмя ядрами). Но после 8 время все еще уменьшается, хотя и медленнее. И около 16 или около того, никаких дальнейших заметных улучшений. Я вообще не анализировал это поведение, но наивно относил его к операциям жонглирования ОС (в данном случае linux slackware 14.2x64) для еще большего сокращения общего времени простоя.


0

Лучший выбор зависит от системы. Итак, вы хотите запустить обе версии в реальной системе, а затем проверить, как система реагирует. Можете ли вы по-прежнему использовать браузер, текстовый редактор и другие вещи в вашей системе? И лучше ли производительность при использовании n потоков, а не n-1? Что произойдет, если вы запустите приложение вместе с другим приложением, которое пытается использовать все процессоры?

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

И наконец, рассмотрите возможность разделения вашей работы на большее количество блоков, чем потоков. Причина в том, что разные потоки завершат работу в разное время, а затем вы захотите, чтобы часть работы была передана более быстрым потокам. В противном случае вам придется подождать, пока последний поток не закончится.

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


-4

Я не знаю, как написать это так, чтобы это не звучало «плохо», поэтому просто примите это как дружеское замечание, хорошо?

Учитывая, что средний ПК уже имеет обычно тысячи или более потоков, что заставляет вас думать, что использование 8 против 7 будет иметь какое-то значение? :-)

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


3
Но большинство из этих тысяч потоков не используют 100% CPU, не так ли?
Андреас Рейбранд

1
Использование вдвое большего количества ядер обычно не улучшает время вычислений. На самом деле использование большего количества физических ядер обычно не выгодно, даже если у вас больше логических ядер (через HyperThreading и т. Д .; хотя это может зависеть от конкретной задачи, которую вы выполняете). Источник: опыт прошлого, используя MATLAB Parallel Processing.
Sanchises

1
@Sanchises Это потому, что гиперпоточность использует квазипараллельное чередование инструкций - это эффективно для ветвистого кода и тяжелого кода памяти. Матричные вычисления очень интенсивны в FPU, и для каждого физического ядра используется только один FPU, поэтому гиперпоточность не может вам помочь.
J ...
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.