Ардуино могла быть в 25 раз быстрее! Разница скорости Arduino vs. AVR vs. STM32.

Провел тест, для сравнения скорости выполнения программы на Arduino, AVR и STM32. Результаты мягко говоря удивили. Тестовая программа написанная в Atmel Studio выполнилась в 25 раз быстрее чем на Arduino, но одном и том-же процессоре.

Ардуино могла быть в 25 раз быстрее! Разница скорости Arduino vs. AVR vs. STM32. Arduino, Avr, Stm32, Stm32f103, Тест скорости, Сравнение, Видео, Длиннопост

Еще больше удивило, что AVR обогнал STM32. И дело тут не в архитектуре процессора, не в задержках вызванных ограниченной скоростью доступа к памяти программы (flash latency). Причина в медленных функциях STDPeriph. Многие действия, которые могли бы выполниться за один такт выполняются в лучшем случае за пять, так как находятся внутри функции. Если бы перед оглашением таких функций стояла директива "inline" размер кода и скорость выполнения были-бы значительно выше. После замены медленных функций на прямое обращение к регистрам скорость STM32 утроилась. В CubeMX дела обстоят еще хуже из-за усложненных обработчиков прерываний, callback функций и т.д.

Ардуино могла быть в 25 раз быстрее! Разница скорости Arduino vs. AVR vs. STM32. Arduino, Avr, Stm32, Stm32f103, Тест скорости, Сравнение, Видео, Длиннопост

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


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

Вы смотрите срез комментариев. Показать все
2
Автор поста оценил этот комментарий

коллега код после куба разбирал, там дофигища оверхэда и мертвых кусков, зато под всё сразу и для быстрого старта сойдёт, да я в нём и сам функции/ножки подбирают, а потом пишу в регистры руками

компилятор с -Ox(man gcc) сам инлайнит когда надо

раскрыть ветку (2)
1
Автор поста оценил этот комментарий

Больше всего мне в HAL не понравилась работа с UART...

"-Ox(man gcc) сам инлайнит когда надо" - как интересно, будет время надо будет покопаться с этим компилятором. Хотя я предпочитаю сам прописывать, то, что считаю нужным, а не догадываться, что компилятор оптимизировал, а что нет.

Да, CubeMX для ножек согласен, крутая штука, не надо сидеть с карандашом и перебирать конфигурации, как то его лучше подключить, где ремапить, где нет... У меня пару раз случалось, что-то посадил на ножку (не в STM), а в процессе разработки выясняется, что она нужна для какой-то периферии, с Cube в этом смысле очень удобно. Разработчики HAL и Cube почитали бы это - плеваться начали, что мы их детище только ради ножек используем)))

раскрыть ветку (1)
1
Автор поста оценил этот комментарий
не, ну куб не только ради ножек конечно:)

подобрать кристалл, ещё там удобненько схема тактирования рисуется

а на счёт : "я предпочитаю сам прописывать, то, что считаю нужным, а не догадываться, что компилятор оптимизировал, а что нет.", я не особо мастер в теме, но как понимаю, что там для МК задаются какие то базовые вещи в Makefile типа:


LDFLAGS += --specs=nano.specs --specs=nosys.specs --specs=rdimon.specs

CLAGS = -Wfatal-errors -Wall -ffunction-sections -Wl,--gc-sections -flto -fno-asynchronous-unwind-tables -Wl,--strip-all -mthumb -mcpu=cortex-m0 -IInclude -D STM32F030x6 -Os


Ну и тут как видно "-Os" (s - оптимизация по размеру) не до жиру :)

Вы смотрите срез комментариев. Чтобы написать комментарий, перейдите к общему списку