2010-01-22 5 views
1

Я делаю проект на встроенном устройстве с процессором ARM926Ej-S. Мне нужно выполнить анализ производительности алгоритма на устройстве. Я новичок во встроенной среде и не очень понимаю, что такое анализ производительности для встроенных устройств.Анализ производительности для алгоритмов на встроенных устройствах

Может кто-нибудь сказать, какие параметры следует учитывать для анализа? Как реализовать реализацию?

Спасибо всем

ответ

1

Мой подход к ним должен был бы прочитать в справочном руководстве (http://www.arm.com/miscPDFs/5499.pdf), который должен охватывать все, что вам нужно. Это покажет вам, есть ли блок с плавающей запятой, какие недостатки есть в FPU, что вы должны иметь в виду при использовании DMA, кеш-памяти и макета памяти, а также скорости шины памяти и многое другое, что если вы хотите правильно и эффективно программировать это устройство.

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

+0

спасибо darthcoder. Я рассмотрю справочное руководство. Можете ли вы прочесть мой ответ для комментария Майка в приведенном выше ответе и ответить соответствующим образом. еще раз спасибо – sravan

+0

Если вы уже используете gdb для отладки, вы можете использовать gprof для профилирования. Профилирование происходит двумя способами: один микрофон предпочитает (образец-профиль) и профиль времени. Вместо ручного осмотра вызова вы можете использовать gprof, который уже поддерживает профилирование образца. gprof просто берет callstack-samples автоматически и дает вам список с вызываемыми функциями и сколько процентов от времени выполнения они взяли. Бывают случаи, когда профиль времени был бы более полезен, но я не знаю, поддерживает ли gprof это вообще. Для общего первичного обзора образец-проф должен быть достаточным. – DarthCoder

+0

hi Darthcoder, Я никогда не использовал gprog других других методов профилирования. Но, я узнаю о них, прибегая к нему. Можете ли вы сослаться на некоторые документы относительно этого, если раньше вы делали профилирование. В то же время я прочитаю о профилировании образцов и о том, как их реализовать с помощью gdb. Я также хотел бы сделать профилирование времени. – sravan

2

Какая у вас среда отладки? У вас есть встроенный эмулятор (ICE)? Я рекомендую, чтобы у вас была среда отладки, так что вы можете вручную остановить выполнение в произвольное время и изучить состояние программы, включая стек вызовов (stackshots). Ручная выборка стека вызовов таким образом выявит места в коде, которые отвечают за значительную долю времени, так что вы можете их оптимизировать. Here is a longer explanation.

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

+0

привет Майк, У меня нет среды отладки. Я планирую JTAG для устройства. Я не знаю, можно ли его использовать для этого устройства или нет. Прямо сейчас, я общаюсь с устройством, используя последовательный порт. Я забыл сообщить, что ядро ​​Linux 2.6.20 работает с минимальными приложениями GUI на устройстве.Итак, я использую gdb для отладки моих программ. Пожалуйста, дайте мне знать, могу ли я сделать то же самое, используя gdb. спасибо – sravan

+0

@sravan: Да, если вы можете запускать свою программу под gdb, control-C - это способ прервать ее, чтобы вы могли проверить стек вызовов. Другой способ - запустить программу, и, хотя она работает, используйте программу pstack или lsstack. Возможно, вам придется обернуть цикл вокруг вашей программы, чтобы он «работал» достаточно долго, чтобы брать ваши образцы. –