Сильно переменное время выполнения в функциях Cython - PullRequest
0 голосов
/ 25 октября 2018

У меня проблема измерения производительности при выполнении перехода на Cython из скомпилированных C-функций (через scipy.weave), вызываемых из механизма Python.

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

Например.Время накопления функции Cython, выполненной 9 раз за 5 повторений (после прогрева 5 выполнений - не учитывается функцией профилирования) принимает:

  • в первом раунде 215,627339 секунд
  • во втором раунде 235,336131 секунда

Каждое выполнение вызывает функции много раз с разными, но фиксированными параметрами.Возможно, эта изменчивость может зависеть от загрузки процессора тестируемой машины (выделенной в облаке), но мне интересно, может ли такая изменчивость (почти 10%) каким-то образом зависеть от Cython или отсутствия оптимизации (я уже использую подсказки по разделению,проверка границ, обтекание, ...).

Есть идеи, как получить надежные метрики?

Ответы [ 2 ]

0 голосов
/ 25 октября 2018

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

После того, как вы контролируете внешние изменения, вам необходимо изучить внутренние.Вы ничего не сказали о цвете вашей функции.Некоторые (многие?) Функции имеют доступные ярлыки для тривиальностей, управляемых данными, таких как умножение на 0 или 1. Некоторые зависят от явной или скрытой итерации, которая зависит от данных.Вам необходимо проанализировать входные данные в отношении алгоритма.

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

0 голосов
/ 25 октября 2018

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

...