Анализ пиков в измерении производительности

У меня есть набор функций C ++, который выполняет некоторые операции, связанные с обработкой изображений.Как правило, я вижу, что конечный результат доставляется в диапазоне 5-6 мс.Я измеряю время, используя ---- +: = 0 =: + ---- Win32 API.Но при работе в непрерывном цикле из 100 изображений я вижу, что для некоторых изображений производительность возрастает до 20 мс.Мой вопрос заключается в том, как мне анализировать такие проблемы.По сути, я хочу определить, вызваны ли пики из-за некоторой задержки в этом коде или какая-то другая задача запущена внутри ЦПУ, из-за которой эта операция заняла время.Я пытался использовать ---- +: = 1 =: + ---- API, чтобы увидеть, сколько времени мой поток провел в ЦП, но не могу сделать вывод на основании этих чисел.Каков стандартный способ устранения неполадок этих типов?
4 голоса | спросил Naveen 6 WedEurope/Moscow2017-12-06T09:43:37+03:00Europe/Moscow12bEurope/MoscowWed, 06 Dec 2017 09:43:37 +0300 2017, 09:43:37

3 ответа


0
Каков стандартный способ устранения неполадок этих типов?Существуют операционные системы реального времени (RTOS), которые гарантируют такие задержки.Это совершенно другой класс операционных систем, чем Windows или Linux.Но, тем не менее, есть кое-что, что вы можете сделать с задержками даже в ОС общего назначения.1. Избегайте системных вызововКак только вы попросите свою ОС прочитать или записать что-то на диск - никаких гарантий относительно задержек нет.Итак, избегайте любых системных функций на вашем критическом пути:даже такие функции, как gettimeofday (), могут вызвать непредсказуемые задержки, поэтому вам следует избегать любых системных вызовов в критичном по времени коде;используйте другой поток для выполнения ввода-вывода и передачи данных через общий буфер в ваш критический код.Если ваша кодовая база большая, используйте такие инструменты, как ---- +: = 0 =: + ---- в Linux или ---- +: = 1 =: + ---- в Windows для отслеживания системных вызовов.2. Избегайте переключений контекстаМногопоточность в Windows является преимущественной.Это означает, что есть системный планировщик, который может остановить ваш поток в любое время и запланировать другой поток на вашем процессоре.Как и ранее, существуют RTOS, которые позволяют избегать таких переключений контекста, но вы можете с этим что-то сделать:убедитесь, что для системных и других задач осталось хотя бы одно ядро ​​процессора;привязать каждый из ваших потоков к выделенному процессору с помощью ---- +: = 2 =: + ---- (Windows) или ---- +: = 3 =: + ---- (Linux) - этоэффективно намекает на системный планировщик, чтобы избежать планирования других потоков на этом процессоре;убедитесь, что аппаратные прерывания идут на другой процессор;обычно прерывания идут на CPU 0, поэтому проще всего связать ваш поток с CPU 1+;увеличьте приоритет вашего потока, так что планировщик с меньшей вероятностью переключит ваш поток на другой.Существуют такие инструменты, как ---- +: = 4 =: + ---- (Linux) и ---- +: = 5 =: + ---- (Windows) для подтверждения переключения контекста.3. Избегайте других недетерминированных функцийЕще несколько источников неожиданных задержек:отключите подкачку, чтобы вы точно знали, что память вашего потока не будет заменена на медленном и непредсказуемом диске;отключить турбо-ускорение ЦП - после высокопроизводительного повышения ЦП всегда происходит замедление, поэтому ЦП остается без тепловой мощности (TDP);отключить гиперпоточность - с точки зрения планировщика это независимые процессоры, но на самом деле производительность каждого гиперпоточного процессора зависит от того, что другой поток делает в данный момент.Надеюсь это поможет.
ответил Andriy Berestovskyy 6 WedEurope/Moscow2017-12-06T19:10:41+03:00Europe/Moscow12bEurope/MoscowWed, 06 Dec 2017 19:10:41 +0300 2017, 19:10:41
0
Причиной внезапных пиков во время обработки могут быть любые операции ввода-вывода, прерывания, запланированные процессы и т. Д.Такие всплески очень часто встречаются с учетом таких операций с малой задержкой /временем обработки.ИМО вы можете рассмотреть их по любой из вышеупомянутых причин (может быть и больше).Самое простое решение - запустить один и тот же эксперимент с большим количеством входов несколько раз и взять среднее значение для окончательного рассмотрения.Чтобы ответить на ваш вопрос о проверке /подтверждении источника всплеска, вы можете попробовать следующее,Проверьте изменение в изображениях - уже исключено согласно вашему комментариюКонтролировать использование ресурсов во время обработки.Проверьте, не засорился ли какой-либо ресурс (% util - это самый простой способ проверить, а утилита SAR /NMON в linux лучше всего с минимальными издержками)Зарезервируйте несколько процессоров в системе (CPU Affinity) для вашего эксперимента, которые предназначены только для вашей программы, и никакие задачи ОС не будут выполняться на них.Taskset - это самая простая утилита для тестирования.Более подробная информация здесь .Запустите эксперимент с этим параметром и проверьте поведение.
ответил Nachiket Kate 6 WedEurope/Moscow2017-12-06T12:34:46+03:00Europe/Moscow12bEurope/MoscowWed, 06 Dec 2017 12:34:46 +0300 2017, 12:34:46
0
Это неприятная вещь, которую вы пытаетесь выяснить, я бы даже не попытался, поскольку трудно прийти к конкретным выводам.В общем, нужно выполнить цикл из многих итераций (я думаю, что 100 кажется слишком маленьким), а затем взять среднее время для обработки изображения.Это исключит любые неожиданные внешние события, которые могут повлиять на производительность вашей программы.Типичный способ проверить, «запущена ли какая-либо другая задача внутри ЦП», - это запустить вашу программу один раз и отметить изображения, которые производят этот всплеск.Например, изображения 2, 4, 5 и 67 занимают слишком много времени для обработки.Несколько раз запустите вашу программу и отметьте еще раз, какие изображения вызывают всплески.Если те же самые изображения производят эти пики, то это не что-то вызванное другой внешней задачей.
ответил gsamaras 6 WedEurope/Moscow2017-12-06T09:57:53+03:00Europe/Moscow12bEurope/MoscowWed, 06 Dec 2017 09:57:53 +0300 2017, 09:57:53

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132