ARM cycle count, как правильно мерять производительность кода. Опции

[Bosicc]

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

И у меня возник вопрос, как правильно оценить эффективность и производительность кода?
Ну вот, например как оценить скорость выполнение FFT?
Я так понимаю, было б правильно посчитать сколько он занимает тактов, а потом умножить на время одного такта.
Тогда под разными процессорами можно было б сказать, за сколько выполнится преобразование.
Для Блекфин как то получены цифры, но вот с помощью чего?
В Keil можно померить время выполнения функции в Симуляторе. Но что это за время? Ведь код может выполнятся из внутреннего кеша процессора или из внешней памяти.

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

[aaarrr]

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

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

[Bosicc]

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

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

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

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

[aaarrr]

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

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

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

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

[sergeeff]

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

[scifi]

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

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

[Bosicc]

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

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

Код

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

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

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

[_Pasha]

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

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

[aaarrr]

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

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

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

[Bosicc]

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

Архитектура ядра - это я имел в виду чему будут равны вейтстейты под тот или иной процессор.
А как они умеют его учитывать? Они выдают количество тактов или время необходимое на выполнение куска кода?
Я искал тулзы которые показывали б количество тактов инструкций + количество вейтстейтов.

[KRS]

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

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

[aaarrr]

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

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

[AlexandrY]

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

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

[Bosicc]

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

Я запускаю Keil Simulator, ставлю брейкпоин на нужную мне функцию, открываю Performance Analyzer и вижу в нем
Calls, Time(Sec), Time(%). Следовательно, могу померять только время. А где можно посмотреть Cycles?
У меня uVision V3.62c, MDK 3.22a

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

[AlexandrY]

А.. , так у вас притензии к Performance Analyzer-у Keil-а.
Смотрите описание команды командной строки Keil-а - PerformanceAnalyze

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

[tocha]

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

почему три?
по документации один вроде, если результат не используется на следующем такте и не модифицируется смещение.
или я - неправ?

[klen]

мое мнение - 1 лапка + 1 осцилограф
реальное время

[KRS]

мое мнение - 1 лапка + 1 осцилограф
реальное время

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

[aaarrr]

почему три?
по документации один вроде, если результат не используется на следующем такте и не модифицируется смещение.
или я - неправ?

По документации - S+N+I (+S+N if R15 loaded), т.е. 3 или 5 тактов.

P.S. Пардон, речь о Cortex-M3? Тогда вы отчасти правы, но один такт это все равно исключение.

[KRS]

По документации - S+N+I (+S+N if R15 loaded), т.е. 3 или 5 тактов.

А я вроде мерял на ARM7 LPC - 2 такта получалось.

Кстати если работать с FAST IO у LPC эти регистры прямо к ядру подключены то на ARM7 цикл

Код

while(1) {
FIO0SET0 = 1;
FIO0CLR0 = 1;
}

выполняетя 6 таков - по 2 такта STR и 2 такта branch
а вот на LPC1700 уже за 4 такта - по 1 такту STR и 2 такта branch, потому что если добавить еще пару SET CLR - то цикл становится 6 тактов. (причем мерял на 100 Mhz частоте, но код был из RAM).

[aaarrr]

А я вроде мерял на ARM7 LPC - 2 такта получалось.

На ARM7 STR - 2, LDR - 3/5.

B - тоже 3, так что должно было получится 7 тактов у вашего цикла.

[KRS]

B - тоже 3, так что должно было получится 7 тактов у вашего цикла.

На ARM7 уже давно измерял, наверное там полный регистр FIO использовал 32 бита.
Но вот на Cortex-M3 точно байтовый - меня и поразила скорость, подумал было что PLL слишком сильно разогнал

[ar__systems]

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

Logic Analyzer. У tech-tools удобный для таких измерений -- разрешение 10нс, а периоды можно мерять хоть 1 час хоть 10. самые полезные 500 баксов которые я когда либо потратил на иструменты.

Сообщение отредактировал ar__systems - Dec 4 2009, 00:44

[ViKo]

Я запускаю Keil Simulator, ставлю брейкпоин на нужную мне функцию, открываю Performance Analyzer и вижу в нем
Calls, Time(Sec), Time(%). Следовательно, могу померять только время. А где можно посмотреть Cycles?
У меня uVision V3.62c, MDK 3.22a

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

Запускаете отладку, внизу, в статусе, ближе к правому краю t1: ...
Жмете правой кнопкой мыши... наводите мышь... А время в такты перевести сможете, вы же частоту генератора знаете.
Правда, у меня Keil 4.0

Сообщение отредактировал ViKo - Dec 4 2009, 16:28

[tocha]

А.. , так у вас притензии к Performance Analyzer-у Keil-а.
Смотрите описание команды командной строки Keil-а - PerformanceAnalyze

Открываю mVision3 v3.62с - Смотрю описание PerformanceAnalyze и вижу сноску
что команда не доступна в arm симуляторе.


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