Загрузка процессора

Question

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

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

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

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

UPDATE: Предложения:

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

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

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

4. Не использовать спин-блокировки для потоков с длительным ожиданием

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

Эти предложения имеют большое значение для начинающего, чтобы понять концепции.

Answer 1

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

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

Не не попадете в ловушку извращения вашего кода заранее во имя оптимизации.

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

Answer 2

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

---

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

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

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

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

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

Answer 3

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

Answer 4

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

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

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

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

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

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

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

Answer 5

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

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

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

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

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

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

Answer 6

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

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

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

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

Answer 7

• следуйте методам оптимизации кода.

• рассчитать память ваших операций.

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

Answer 8

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

Answer 9

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

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

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

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

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

Есть настоящее удовлетворение в достижении этой точки.