caxapa.ru :: В большей части моих проектов я согласен с таким подходов. Но был один, в котором была куча матричного матана и адских алгоритмов оптимизации. Вот там скорость была критична, хоть увеличение размера кода раза в 2 или даже в 3 никого бы не

Evgeny_CD, Архитектор (11.12.2017 12:51 - 13:06, просмотров: 208) ответил SciFi на В ымбеддед некая общая "скорость" не особо важна, это же не игровая приставка. Как правило, успевать нужно в нескольких небольших участках кода, а там можно (и нужно!) разобраться локально вплоть до реализации на ассемблере.

В большей части моих проектов я согласен с таким подходов. Но был один, в котором была куча матричного матана и адских алгоритмов оптимизации. Вот там скорость была критична, хоть увеличение размера кода раза в 2 или даже в 3 никого бы не напрягло. Проект был без линуха, под примитивной RTOS - перепиленной FreeRTOS. ARMу было доступно 16М ОЗУ SDRAM.

Ответить

- Это то же самое, просто тот "небольшой участок кода" чрезмерно распух :-) - SciFi(11.12.2017 12:52)
  - Причем там и С++ код-то с трудом понимал его автор - аддский математик (впрочем, хорошо писавший код под GCC на Linux, мы его потом портировали в устройство), так что про asm оптимизацию там никто и не думал вообще :) - Evgeny_CD(11.12.2017 12:56)
    - По мере выставления все более и более строгих констрейнов на плюшки С++ его код становился все быстрее и быстрее, но и мата от него становилось больше :) - Evgeny_CD(11.12.2017 12:58)

Средства и методы разработки