Как найти оптимальное количество воркеров для parfor на виртуальной машине Amazon?
Для каких случаев я должен использовать количество физических и для каких логических ядер?
Есть ли для этого какое-либо "эмпирическое правило"?
Я запускаю скомпилированный код (исполняемый код).
Вопрос : Как найти оптимальное число рабочих для
parforна виртуальной машине Amazon?
В аналогичных, частично определенных ситуациях я начинаю с аналогичного набора основных возражений, таких как выше "Оптимально по тому, какая критериальная функция (полезное удовольствие / штрафное удовольствие) каких параметров и затрат - [TIME] (во-первых, задержка частичного результата, завершение E2E ), [SPACE] ( yesss : объем кэш-памяти и оперативной памяти ), масштабирование, внешние факторы (затраты на электроэнергию, { owned | rented }-затраты на инфраструктуру, затраты на НИОКР, затраты на проектирование/инжиниринг, затраты на контроль качества, проверку/сертификацию -затраты, другие связанные затраты на оплату труда, затраты на политику снижения рисков - и это лишь некоторые из них) ?", уже поднятые в предложении № 2 @Dev-iL, пересказывая мудрость Льюиса Кэрролла, вписанную в «Алису в Стране чудес»:
”Алиса : Куда мне идти?
Кот : Это зависит от того, куда вы идете.
Алиса : Не знаю.
Кот: Тогда неважно, куда ты пойдешь».
это говорит нам о том, что произойдет,
если не иметь
каких-либо и всех критериев, предварительно-определенных:
"( не имеющих target ), любая дорога приведет вас туда..."
Этот вопрос был решен доктором Джином АМДАХЛ (1967 г.) на основе работы профессора Кеннета Э. НАЙТА (1966 г.), и решение заключается в применении «Закона убывающей отдачи», названного в честь бывший, Амдал Лоу. Как для деталей, так и для современной критики наивно примененного оригинала (накладные расходы и атомарные объемы работы) прочитайте это
Шаг 0:
проверить/записать чистое время всех чисто [SERIAL] полностью выполненных разделов C< /strong>ode-under-Rreview ( CuR ), которые находятся "до" и "после" желаемого parfor-конструктор синтаксиса.
Шаг 1:
протестируйте/запишите чистое время всех parfor-{ экземпляров + >расторжение }-накладные расходы. Здесь берутся все правильно масштабированные параметры для типов и размеров сигнатур вызова и возвращаемых значений (CuR должен потратить некоторое время на сериализацию/десериализацию всех из них для каждого вызова, а также должен потратить дополнительное время на SER /DES при подготовке/транспортировке/сборе каждого из "удаленно"-parfor-ed результатов), масштаб MEM-аллоков - это также занимает значительное количество времени по сравнению с CuR, если просто некоторая "мелкая"-вычисление-плотность или память случается, что повторное использование областей неэффективно, параллельно-CuR принимается во внимание). Некоторые из этих дополнительных накладных расходов (записанные в [TIME]-domain) накапливаются «внутри» parfor-украшенных частей кода (и невидимы или не происходят во время чистого-[SERIAL] выполнения кода, поэтому тест/ эталонный тест может потребовать некоторой работы, чтобы изолировать эти дополнительные затраты «внутри» подозрительных операций раздела parfored, которые выделяют и никогда не используют повторно большие области памяти и т. д., если моделирование затрат стремится отсчитывать до центов внешние оплачиваемые расходы на инфраструктуру).
Шаг 2.
протестируйте/запишите атомарность рабочей единицы, введя "осиротевшее" время последней партии рабочих единиц, которая никогда не станет быстрее. (из-за atomicity-of-workunit - неделимой длительности работы, что никакой другой свободный процессор-ядро не поможет)
... следует использовать количество физических и для которых количество логических ядер?
Шаг 3
проверить/записать фактическое соотношение перехвата работы/собственной работы в сети для любого из предоставленных типов кода (независимо от того, какие они помечены как "маркетинговые") - исполнительные единицы (виртуальные устройства, несущие наибольшую неэффективность из-за более высоких задержек, более высоких коэффициентов кражи работы - т.е. ожидайте гораздо более низкой эффективности для любой формы преимущественно вычислительно-интенсивных параллельных рабочих)
Шаг 4
проверить/записать фактическую частоту / размер кэша / условия нехватки ЦП, вызванные оперативной памятью, которые на самом деле вызовут "единицы работы" "там"-исполнение хуже, чем можно было ожидать на {local-| частная сетевая вычислительная инфраструктура.
Шаг 5.
сравните все начисленные затраты для любого количества рассматриваемых ядер/типов, используя должные (и правильно ослабленные< /em> по всем параметрам неэффективности, указанным выше) из шагов 0:4 и используя тарифный план(ы) от любого из ваших поставщиков инфраструктуры, вы получите приблизительные затраты на использование большего/меньшего количества ресурсов для любого заданного временные/финансово-бюджетные ограничения.
Все заслуги принадлежат доктору Джину АМДАХЛ, чью работу ненавидят все маркетологи, продающие как можно больше игрушек с маркировкой «дешево», но малоэффективных и предназначенных только для совместного использования (да, виртуализация означает еще один слой дополнительных накладных расходов и приводит к SHARED совместному выполнению на кремнии ( 0.5 [ns] истощение кэша за счет множества повторных ~350+[ns] повторных выборок ранее уже кэшированных данных снова «через» границу местоположения NUMA, что приводит к повторяющимся RAM-I/O-каналам ' узкие места - это наименьшая потеря, о которой здесь можно упомянуть) - совместное использование/виртуализация, введенная кража работы ЦП, покажет вам количество украденных тактов ЦП, которые ваши вычислительные полезные нагрузки не смогли вычислить в пользу другие, «делящиеся» этой самой «облачно-небесной мечтой», оплачиваемой вами на основе «за час использования», вне вашего контроля).
Облака могут быть хороши для редкого запуска некоторых специальных задач с низкой вычислительной нагрузкой (чем DSP, очевидно, не является, не так ли?) с минимальной междоменной связью/координацией, группой задач разумного размера, которые могут выиграть от распределенного, латентное маскирование, (наивное)-грубое выполнение многих таких "поверхностных" и "не очень требовательных" рабочих единиц (много раз неэффективных как таковых с точки зрения HPC -класс вычислений ), но очень "дешевые"-(просто)-звучащие тарифные планы заставляют осознать, что собственная, частная инфраструктура будет стоить (если принять решение в свое время, прежде чем уже потратить эти расходы ) примерно такие же, как использование «дешевого» арендованного во второй, третий, ... n-й раз.
[Можете спрашивать реальные компании об их корректировках затрат и реальной ответственности, даже если существуют туманные мечты «консультантов», практические истории, не стесняйтесь спрашивать :o) ]
Таким образом, решение о оптимальных затратах, сформулированных в вашем контексте, остается за вами. Всегда.
parfor(то есть, возможно, переписывание вашего алгоритма позволит ему работать достаточно быстро на одном ядре)? Есть ли у вас ядра графического процессора? Я думаю, что ответ зависит от конкретного алгоритма, доступного оборудования и цели оптимизации. Единственным правильным ответом на такой общий вопрос было бы запустить его с другими настройками и выяснить. - person Dev-iL schedule 10.11.2019