Перейти к содержанию
    

Здравствуйте, уважаемые армоведы.

Просмотрев внимательно по форуму, я нашел много упоминаний о измерении производительности кода под ARM. Одни меряют время, другие пробуют посчитать циклы (cycle count).

В ветке немного затронули проблему измерения тактов, то детально не обсуждали.

 

И у меня возник вопрос, как правильно оценить эффективность и производительность кода?

Ну вот, например как оценить скорость выполнение FFT?

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

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

Для Блекфин как то получены цифры, но вот с помощью чего?

В Keil можно померить время выполнения функции в Симуляторе. Но что это за время? Ведь код может выполнятся из внутреннего кеша процессора или из внешней памяти.

 

По этому возник еще один вопрос, есть ли какие либо дополнительные тулзы что б мерить не время, а именно cycle count

с учетом всех задержек после выполнения инструкций?

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

По этому возник еще один вопрос, есть ли какие либо дополнительные тулзы что б мерить не время, а именно cycle count

с учетом всех задержек после выполнения инструкций?

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Тулзов, которые учитывали бы все, в природе нет.

Хм... это Вы имеете в виду под АRМ? Потому что для DSP есть профайлеры, которые довольно неплохо меряют cycle count.

ввести некоторый поправочный коэффициент с учетом вейтстейтов, загрузки шин, работы кэша и т.п

А есть идеи как примерно рассчитать этот коэффициент? Может есть какие доки?

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Хм... это Вы имеете в виду под АRМ? Потому что для DSP есть профайлеры, которые довольно неплохо меряют cycle count.

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

С DSP все проще - тулзы как правило создает сам разработчик кристалла, который знает его досконально.

 

А есть идеи как примерно рассчитать этот коэффициент? Может есть какие доки?

ИМХО, только получить опытным путем.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Выделяешь какой-нибудь свободный и доступный pin. Настраиваешь его на вывод и по умолчанию пишешь в него "0". Перед вызовом функции устанавливаешь в "1", после вызова "0". На осциллографе меряешь время. Самый точный вариант для реального железа.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

И у меня возник вопрос, как правильно оценить эффективность и производительность кода?

"Правильно-неправильно" - это скорее философский вопрос.

Гораздо понятнее вопрос типа "за сколько секунд (микросекунд, миллисекунд) мой процессор выполнит мою задачу?". Чтобы получить ответ на этот вопрос, я обычно секундомером пользуюсь. Зацикливаю задачу, чтобы общее время выполнения было 30-60 секунд и засекаю время. На мой взгляд, это самый "правильный" способ :-)

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Чтобы получить ответ на этот вопрос, я обычно секундомером пользуюсь. На мой взгляд, это самый "правильный" способ :-)

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

А речь идет как оценить качество кода, в не зависимости от конкретной реализации железа.

Если написать код:

MOV   R0,R1  // 1 cycle
// stolen cycle - processor wait x cycles 
LDR    R0,R2 // 2 cycle

То суммарное время будет 3 такта + х тактов которые будет стоять процессор.

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

Как Вы предлагаете оценивать несбалансированные и сильно ветвящиеся алгоритмы ? Допустим, с первыми - по наихудшему прогнозу. А со вторыми ?

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

Ну, обычные вейтстейты умеет учитывать большинство симуляторов, только причем тут "архитектура ядра"?

 

P.S. LDR выполняется 3 такта.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Ну, обычные вейтстейты умеет учитывать большинство симуляторов, только причем тут "архитектура ядра"?

 

Архитектура ядра - это я имел в виду чему будут равны вейтстейты под тот или иной процессор.

А как они умеют его учитывать? Они выдают количество тактов или время необходимое на выполнение куска кода?

Я искал тулзы которые показывали б количество тактов инструкций + количество вейтстейтов.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

Так берете таймер работающий на частоте ядра и вперед: содержимое счетчика после - содержимое счетчика до.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

А как они умеют его учитывать? Они выдают количество тактов или время необходимое на выполнение куска кода?

Да, просто симулятору нужно сначала объяснить, что для доступа к такому-то региону памяти нужно столько-то тактов.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Keil считает так как будто код выполняется из кэша.

Keil правильно показывает такты, можете базироваться на его результатах.

Добавлять в инструкции такты доступа к памяти и периферии может IAR, Multi2000, RVDS ...

 

В Keil можно померить время выполнения функции в Симуляторе. Но что это за время? Ведь код может выполнятся из внутреннего кеша процессора или из внешней памяти.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Keil считает так как будто код выполняется из кэша.

Keil правильно показывает такты, можете базироваться на его результатах.

 

Я запускаю Keil Simulator, ставлю брейкпоин на нужную мне функцию, открываю Performance Analyzer и вижу в нем

Calls, Time(Sec), Time(%). Следовательно, могу померять только время. А где можно посмотреть Cycles?

У меня uVision V3.62c, MDK 3.22a

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

А.. , так у вас притензии к Performance Analyzer-у Keil-а. :biggrin:

Смотрите описание команды командной строки Keil-а - PerformanceAnalyze

 

Я запускаю Keil Simulator, ставлю брейкпоин на нужную мне функцию, открываю Performance Analyzer и вижу в нем

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Присоединяйтесь к обсуждению

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

Гость
Ответить в этой теме...

×   Вставлено с форматированием.   Вставить как обычный текст

  Разрешено использовать не более 75 эмодзи.

×   Ваша ссылка была автоматически встроена.   Отображать как обычную ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставлять изображения напрямую. Загружайте или вставляйте изображения по ссылке.

×
×
  • Создать...