Вопрос

Q1.Каковы наилучшие практики для написания кода, который не потребляет процессор, но при этом обеспечивает отличную производительность?Вопрос очень общий.То, что я ищу здесь, - это перечислить различные практики, используемые для разных сред?советы по отладке помимо process-monitor / диспетчер задач

Редактировать:Я не говорю о процессах, связанных с вводом-выводом.Я говорю о процессе, привязанном к процессору.Но здесь я не хочу, чтобы мой процесс продолжал перегружать процессор.Если у меня 4-ядерные машины и если я запускаю четыре простых цикла в рамках процесса, потребление процессора возрастает до 400%, пока приложение / процесс не будет запущено.

Я ищу здесь некоторый опыт по теме, с которой каждый бы так или иначе столкнулся.например ,Я отлаживал, как только приложение загружало процессор в Windows, поскольку оно непрерывно выполняло цикл поиска несуществующего файла.

Как я могу написать свою программу таким образом, чтобы два разных приложения, привязанных к процессору, работали бесперебойно (давали хороший отклик)?

Обновить: Предложения:

  1. Напишите хороший чистый код, затем профилируйте свое приложение, а затем оптимизируйте.(Спасибо, Тед, за совет)

  2. Проще переписать / редизайн / рефакторинг кода, чем профилировать и исправлять его.

  3. Используйте профилировщик для отладки вашего приложения

  4. Не используйте spinlocks для потоков с длительным ожиданием

  5. Выбор алгоритма

Эти рекомендации помогут новичку вникнуть в суть концепций.

Это было полезно?

Решение

Во-первых, напишите хороший чистый код.Делайте все как можно проще.После этого повторяйте следующее до тех пор, пока не будете удовлетворены скоростью работы программы:

  1. Составьте профиль его исполнения.
  2. Найдите те части, где он проводит больше всего времени.
  3. Ускорьте эти части.

Делай не попадитесь в ловушку, заранее искажая свой код во имя оптимизации.

Запомни Закон Амдхала.Вы не добьетесь заметных улучшений, ускоряя то, что уже отнимает всего 1% времени вашей программы.Вы получаете максимальную отдачу от своих затрат на оптимизацию, ускоряя ту часть, на выполнение которой ваша программа тратит большую часть своего времени.

Другие советы

Делайте как можно меньше работы.


Поскольку вы отредактировали свой первоначальный вопрос, я добавлю сюда еще несколько мыслей, чтобы рассмотреть конкретную ситуацию, которую вы описали.

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

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

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

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

  • Используйте профилировщик неукоснительно.Не полагайтесь на здравый смысл при поиске узких мест.
  • Изучите обозначение big-O, запомните big-O для распространенных алгоритмов.
  • Любой ценой избегайте напряженных циклов ожидания.
  • В случае embedded узнайте, как сделать так, чтобы код помещался в кэш кода, что иногда может привести к десятикратному ускорению в жестких циклах.
  • При высокоуровневой многоуровневой разработке узнайте, как эффективно кэшировать данные (например, чтобы свести к минимуму количество инструкций DB).

Если вам нужен чисто прирост загрузки процессора, то вам нужна нотация big-O.Вам нужно решить, как заставить ваши алгоритмы работать при минимально возможных вычислениях.

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

Некоторые более важные вещи, на которые следует обратить внимание при оценке производительности, это

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

Можете ли вы уменьшить объем данных, над которыми работаете?Если вы сможете легко разместить все это в памяти, вы сможете повысить производительность здесь.Кстати, если вы поместите слишком много данных в память, это может иметь противоположный эффект.

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

Я говорю о процессе, привязанном к процессору.Но, здесь я не хочу, чтобы мой процесс продолжал зависать ПРОЦЕССОР.Если у меня 4-ядерные компьютеры и если я запускаю четыре простых цикла в рамках процесса, процессор потребление возрастает до 400%, пока приложение / процесс не будет запущено.

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

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

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

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

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

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

  • Используйте отложенные значения и / или другой вид кэширования
  • Тщательно выбирайте свои алгоритмы
  • следуйте методам оптимизации кода.

  • вычислите объем памяти ваших операций.

  • рассчитайте время выполнения каждой операции.
    (обозначение большой буквы o)

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

Это несовместимо.

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

Что касается последнего, ну, в последнее время я написал кое-какой код, который использует плохо спроектированный Алгоритмы, привязанные к процессору, и новый процессор Intel I7 стали моим спасителем.Учитывая, что каждое из четырех ядер способно запускать два потока, я просто пытаюсь ограничить использование потоков моей операционной системы пятью или шестью на приложение, и у меня все еще есть процессор, доступный для переключения в другое окно для запуска kill команда.По крайней мере, до тех пор, пока я не переведу систему в режим подкачки из-за утечки пространства.

Хорошие предложения здесь.Чем проще вы напишете код, тем больше времени сэкономите.

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

Обычная история этого, в зависимости от размера программы, заключается в поиске и устранении ряда проблем с производительностью, каждая из которых дает ускорение от 10% до 50% (больше, если есть серьезная проблема).Это дает общее ускорение, возможно, в 10 раз.

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

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

Достижение этой точки приносит истинное удовлетворение.

Лицензировано под: CC-BY-SA с атрибуция
Не связан с StackOverflow
scroll top