Помощь - Поиск - Пользователи - Календарь
Полная версия этой страницы: Оптимизация проекта в ARM
Форум разработчиков электроники ELECTRONIX.ru > Микроконтроллеры (MCs) > Cредства разработки для МК > IAR
SasaVitebsk
bb-offtopic.gif
Некоторые моменты при изучении любого вопроса выпадают из поля зрения. У меня по крайней мере. Видимо мозги "отбрасывают" то что считают "несущественным". А определить что "существенно", а что нет - на этапе изучения предмета практически невозможно. Вот и получается ... smile.gif

Когда Си изучал, маленький раздел про дополнения в версии С99 - мозг выкинул. С stdint начал работать потому, что увидел в какой-то из библиотек GCC и мне понравилось. Даже не догадался, что эта библиотека есть в IAR. Работал тогда с AVR, а библиотека эта только в DLIB. То есть по умолчанию она не подключена. Поэтому я выдрал библиотеку из GCC, доработал напильником и пользовался. sad.gif
В детали не вникал.

Сейчас, в одной из веток, zltigo обратил внимание на типы int_least8_t и я бросился читать. Оказалось буквально 10 строк, которые я упустил. На книгу не фиг пенять. Просто, чтобы понять, надо через себя пропустить. Осмыслить необходимость и потом уже применять.

Но ведь таких моментов много.

Для AVR, я, на первом этапе, просматривал результирующие листинги, чтобы понять как писать на Си, чтобы компилятор генерил прогу найболее эффективно. Это неплохой способ изучения, но слишком долгий. Пока нарабатываются приёмы и появляются знания.
Сейчас перехожу к ARM. Понятно что есть особенности архитектуры. Они явно сказываются. Например вызов п/п совершенно по другому построен. Количество регистров другое и это сказывается. Система комманд и прочее.

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

1) Ну например. Для AVR передача параметров в п/п осуществляется ч/з регистры. Если не влазит, то ч/з стек. В связи с этим нецелесообразно было передавать большое количество параметров и оперировать с длинными параметрами. В некоторых случаях, я "укорачивал" параметры перед передачей ну и так далее. Хотелось бы узнать как эффективнее поступать здесь.

2) Стоит ли работать с "промежуточными типами" ну например int16. Насколько это усложняет жизнь процу?

3) Насколько хорошо проц работает с табличным пересчётом? В AVR я часто пользовался этим при сложных логических операциях, чтобы ускорить получение результата. Здесь я вижу система команд неплохо заточена под сложные операции. Например, то что у AVR отвратительно реализуется - это сдвиги на N разрядов. Здесь - песня. У меня этого много в проекте.
Вот например получение CRC8 таблично будет быстрее или медленнее чем прямым пересчётом. И на сколько.

Хотелось бы услышать советы, мнения выссказывания или ссылки.
Заранее благодарю.
zltigo
Цитата(SasaVitebsk @ Jun 17 2009, 14:19) *
1) Ну например. Для AVR передача параметров в п/п осуществляется....

В певом приближении так-же. Вообще передавать большое количество параметров зачем? Эта функция вызыватсся много раз? Нет? Тогда лююое количество параметров и инлайнить. Либо у меня в таких кусках со многими перемеными хорошо используются макросы.
Цитата
2) Стоит ли работать с "промежуточными типами" ну например int16. Насколько это усложняет жизнь процу?

В общем случае, естественно, нет.
Цитата
Вот например получение CRC8 таблично будет быстрее или медленнее чем прямым пересчётом. И на сколько.

Ну можете для таких вырожденных задач и сами померять, и сами, ну хотя-бы команды в листинге посчитать не вникая в первом приближении в их суть.
Dog Pawlowa
Цитата(SasaVitebsk @ Jun 17 2009, 14:19) *
Хотелось бы услышать рекомендации спецов, активно работающих с этими процами. Для повышения производительности результирующего кода.

Да ничего нового - все тот же инлайн (хм, или макросы - споры не затевать! smile.gif ) с оптимизацией.
Чтобы передавать меньше параметров без инлайна - указатели на выровненные структуры (ну или индексы).
Ну и массивы функций, в том числе и в качестве костыля при работе без ОС для нарубки процесса.
sergeeff
В ответ на вопрос о промежуточных типах:

Цитата(zltigo @ Jun 17 2009, 14:46) *
В общем случае, естественно, нет.



Дело обстоит не так. Два простых примера для иллюстрации: (VS2008 ARM)

Код
short wtest(short x)
{
   short y = 5;
   return x+y;
}


компилируется в:
Код
         add         r3, r0, #5
         mov         r0, r3, lsl #16
         mov         r0, r0, asr #16
         mov         pc, lr
а

Код
int wtest(int x)
{
   int y = 5;
   return x+y;
}
в
Код
         add         r0, r0, #5
         mov         pc, lr

Разница на лицо.
Это же относится к 8-битным типам.
zltigo
Цитата(sergeeff @ Jun 17 2009, 20:48) *
В ответ на вопрос о промежуточных типах:
Дело обстоит не так. Два простых примера для иллюстрации: (VS2008 ARM)

Ну и что не так? Стоит пользоваться промежуточными типами - ответ мною дан - НЕТ.
Приводим пример обратного и возражаем "дело обстоит не так"? Так о чем мы это?
Rst7
Цитата
Разница на лицо.


Именно. Первый код - унылое гуано с точки зрения портабельности. Надо пользовать int_fast16_t. Пользовать регистровые переменные размером меньше регистра нужно только в самом крайнем случае (например, арифметика по модулю 2^16 при размере регистра 32).

Кстати, это же относится и к портированию с 32хбитного камня на 64хбитный. Опять изобретение sad.gif - int остался 32хбитным... Значит, надо пользовать int_fast32_t. Нет в жизни счастья...
zltigo
Цитата(Rst7 @ Jun 17 2009, 21:02) *
Именно. Первый код - унылое гуано с точки зрения портабельности.

И одновременно типичнейший код (ну будет char) для писателей на восьмибитниках в подвляющем числе случаев переносящих сию привычку и на другие платформы sad.gif
sergeeff
Уважаемый гуру!

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

Вопрос: "Стоит ли работать с "промежуточными типами" ну например int16. Насколько это усложняет жизнь процу?"
Ответ: "В общем случае, естественно, нет."

Вопрос стоит у последнего предложения. Соответственно, на него и ответ: "Процу жизнь в общем случае, естественно, нет". Значит не усложняет.

Это меня сильно удивило, потому и привел пример.
scifi
Цитата(SasaVitebsk @ Jun 17 2009, 15:19) *
Хотелось бы услышать рекомендации спецов, активно работающих с этими процами. Для повышения производительности результирующего кода.
...
Хотелось бы услышать советы, мнения выссказывания или ссылки.
Заранее благодарю.

Мне кажется, Вы неверно выбрали приоритет. На мой взгляд (исходя из личного опыта) читаемость/понимаемость кода в подавляющем большинстве случаев важнее, чем его скорость. Тут уместно вспомнить об известном высказывании Дональда Кнута о преждевременной оптимизации (если не в курсе, советую поискать).
ARM хорош тем, что для многих задач производительности достаточно при использовании языка Си без "доработки напильником". Этим надо пользоваться. Лучше быстро и эффективно решать реальные задачи, чем бесконечно ковыряться в отдельных инструкциях процессора, выжимая из него ещё одну микросекунду. Это тем более актуально, так как "традиционный Си для десктопов" хорошо исполняется на ARM - ведь это 32-разрядный процессор.
Конечно, есть применения, где нужно выжать из процессора всё до последнего такта. Но это редкость. Руководствоваться такой философией при обычных разработках - вредно.
zltigo
Цитата(sergeeff @ Jun 17 2009, 22:04) *
Вопрос стоит у последнего предложения.

Наверное, я недостаточно знаю правила русского языка sad.gif, в какой-то степени это мне простительно smile.gif. Ответ давался на ПЕРВЫЙ вопрос а не на его повтор c уточнением на другой лад.
Сочетание "Стоит ли работать с "промежуточными типами - В общем случае, естественно, нет". Вполне нормально звучит.
А фраза "Насколько это усложняет жизнь процу - В общем случае, естественно, нет." Уже звучит не совсем как-то законченной по-русски sad.gif. Или мне кажется, что при ответе утвердительно на вторую часть таким образом поставленного вопроса принято слегка переповторять? Првильно - "усложняет/не усложняет". И вообще ответ "Нет" для ответа на вопрос "Насколько" не подходит smile.gif
singlskv
Цитата(SasaVitebsk @ Jun 17 2009, 15:19) *
2) Стоит ли работать с "промежуточными типами" ну например int16. Насколько это усложняет жизнь процу?
Для локальных переменных(и параметров функций) всегда нужно стремиться к 32бит unsigned,
все остальное менее важно и Вы это поймете в процессе освоения...
sergeeff
Цитата(zltigo @ Jun 18 2009, 00:00) *
Наверное ...

Главное, что автору топика все объяснили, в конце концов.
SasaVitebsk
Цитата(scifi @ Jun 17 2009, 23:30) *
Мне кажется, Вы неверно выбрали приоритет. На мой взгляд (исходя из личного опыта) читаемость/понимаемость кода в подавляющем большинстве случаев важнее, чем его скорость. Тут уместно вспомнить об известном высказывании Дональда Кнута о преждевременной оптимизации (если не в курсе, советую поискать).
ARM хорош тем, что для многих задач производительности достаточно при использовании языка Си без "доработки напильником". Этим надо пользоваться. Лучше быстро и эффективно решать реальные задачи, чем бесконечно ковыряться в отдельных инструкциях процессора, выжимая из него ещё одну микросекунду. Это тем более актуально, так как "традиционный Си для десктопов" хорошо исполняется на ARM - ведь это 32-разрядный процессор.
Конечно, есть применения, где нужно выжать из процессора всё до последнего такта. Но это редкость. Руководствоваться такой философией при обычных разработках - вредно.

Есть 2 типа задач. Первая, где производительность нужна "не меньше". Если процессор справляется с задачей, то дальнейшая оптимизация нецелесообразна. Вторая там где рост производительности процессора(программы) приводит к росту производительности изделия или улучшению других его потребительских свойств.
В данном случае у меня - вторая задача. При этом оптимизации будет подвергаться не вся программа, а только необходимые её части. В частности одно прерывание и несколько подпрограмм.

Тем не менее вопрос задаётся не применительно к проекту, а применительно к процессору. Знания нужны безотносительно к текущей задаче. Они всегда нужны. Например, для более эффективного написания следующего проекта. Кроме того, некоторые знания сложно или долго получать прямым способом. Так как для этого надо произвести исследования. Править и измерять многократно. Это отнимает массу времени и есть вероятность того, что кто-то этот путь уже прошёл. Вот поэтому я обратился к спецам.

И меня они понимают, так как, наверняка, сами оценивали эти вопросы. Возможно неоднократно.

Чтобы понять насколько вы неправы приведу отрывок описания версий при отладке. History так сказать smile.gif
Код
102    Рабочий вариант. ... Производительность 4547 из возможных 3072.
103    Немного оптимизирован по скорости. ...  ... Производительность 3894 из возможных 3072.
105    Переписана п/п ... для увеличения скорости .... Увеличили размер передаваемой структуры Status. И переделали принцип её
    передачи. Производительность 2722 из 3072.
106    Вставки на ассемблере. роизводительность выросла не значительно.
107    Вернулись назад и перешли на ... Производительность 2722 из 3840.
108    Перешли к двухбитной передаче ...
110    Рабочий вариант на .... Производительность
    2722 из 3840. Счётчик в Statusе. Два бита синхронизации.
    Автосинхронизация.
112    Рабочий вариант на ... Новый вывод ... Используется вывод по
    4 бита. Отслеживаются границы ... Производительность 1620
    из 3840. Ввели понятие средней загрузки для оценки производительности.
    Она составила 1092(3840). ...
113    Промежуточный вариант. ... Средняя
    загрузка составила 562(3840).
114    Рабочий вариант. Вывод по 4 бита. Средняя загрузка составила 94(3840),
    максимальная - 1247(3840) на ... ...  387/727
    соответственно. В процентном отношении для ... - 2% / 32%.


Если сравнить верх и низ, то видно что поначалу процессор вообще не справлялся с задачей (загрузка 148%), а в последствии, благодаря изменению алгоритма и оптимизации справлялся с запасом на выбраной тестовой задаче (загрузка 32%).
Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.
Invision Power Board © 2001-2025 Invision Power Services, Inc.