Вход Наше всё Теги codebook 无线电组件 Поиск Опросы Закон Воскресенье
23 ноября

О смысле всего сущего 0xFF Средства и методы разработки Мобильная и беспроводная связь Блошиный рынок Объявления

Микроконтроллеры PLD, FPGA, DSP AVR PIC ARM, RISC-V Технологии Кибернетика, автоматика, протоколы Схемы, платы, компоненты

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

801175 Топик полностью

Evgeny_CD^{Архитектор} (11.12.2017 11:50, просмотров: 259) ответил SciFi на Есть какой-то тулчейн для Арма TASKING VX-toolset. О себе пишут, что генерирует код огого, быстрый и компактный. А реальное сравнение с Яром кто-то делал? Вроде бы Яр лидер по качеству генерируемого кода.

Небольшое замечание - а какова метрика качества кода?

Ответить

- Две метрики: размер и скорость. Очевидно же! То, что код не должен глючить, кагбэ подразумевается :-) - SciFi(11.12.2017 11:54)
  - В части отсутствия глюков солидарен, но вот компилер всего так и не создан. Evgeny_CD(466 знак., 11.12.2017 12:10, ссылка, ссылка)
    - Ну кагбэ были слухи, что некоторые компиляторостроители вставляют детектор дристонов, который выплёвывает гениальный код когда надо. Типа как дизельгейт. Но вообще придумали же какой-то CoreMark. Интереснее, конечно, отзывы реальных юзверей: SciFi(60 знак., 11.12.2017 12:32)
      - Недавно ужимал время на дабловую математику из определенного референса. Участие принимали GCC 4.8 и Keil 5.17. В зависимости от крыжиков и ручных оптимизаций кода (на Си) получил до 15 раз быстрее на GCC и до 8 раз на Keil. Так как часть тестов Vit(494 знак., 11.12.2017 13:56)
      - Вот "перекомпилировал свой код, и он ужался в два раза, и насрать на скорось" - вполне себе метрика, это я понимаю. Evgeny_CD(185 знак., 11.12.2017 12:40)
        
        В ымбеддед некая общая "скорость" не особо важна, это же не игровая приставка. Как правило, успевать нужно в нескольких небольших участках кода, а там можно (и нужно!) разобраться локально вплоть до реализации на ассемблере. - SciFi(11.12.2017 12:45)
        
        И сколько удаётся выиграть по скорости, если сравнивать ассемблер с ИАРом? - йцукен(11.12.2017 13:36)
        
        Из опыта. Ускорение низкоуровневых процедур GUI, работающего с простым frame buffer. Оптимизация С кода - 20 раз за неделю (на входе был эпичный говнокод). Асм код - 10% за неделю на показавшемся нам перспективном куске. - Evgeny_CD(11.12.2017 13:50 - 13:54)
        
        тут зависит от стиля программирования на С. Я как захерачу X-макросы, что все работает только на высшей оптимизации. И что тут сравнивать? Если писать в ассемблерном стиле на С, будет минимальная разница. - VLLV(11.12.2017 13:43)
        
        Если можно, поясните на конкретном примере. Вот функция, работу которой я хотел бы ускорить (FIR-фильтр). Это в ассемблерном стиле? И в каком другом стиле это можно написать? йцукен(551 знак., 11.12.2017 14:31)
        
        мой фир 0men(778 знак., 11.12.2017 15:47)
        
        Сомневаюсь, что фильтр с копированием данных быстрее фильтра на круговом буфере. Кроме того, использование кругового буфера развязывает операции засовывания данных в буфер и собственно фильтрации. - йцукен(11.12.2017 16:26)
        
        Если там можно применить SIMD, то лучше ручками, компилятор сам вряд ли догадается. - SciFi(11.12.2017 14:57)
        
        ИАР не догадывается. Вот мой вариант с SIMD; к сожалению, выигрыш по скорости в пределах статистической погрешности. йцукен(762 знак., 11.12.2017 16:29)
        
        Пример кода от ARM. За счёт встроенных функций, это больше ассемблер, чем Си. Цикл фильтра функции arm_fir_fast_q15() для Cortex-M4 (комментарии вырезаны для наглядности). Из сишных остались лишь инкремент, декремент и условие цикла: Nikolay_Po(691 знак., 11.12.2017 15:34)
        
        Хардкорненько :) - Evgeny_CD(11.12.2017 15:37)
        
        Местами ещё и фееричненько. Ручное разматывание цикла: SciFi(1166 знак., 11.12.2017 15:41)
        
        От открытая либа от ARM для NEON -> Для примера FIR Evgeny_CD(202 знак., 11.12.2017 15:21, ссылка)
        
        CMSIS DSP, там тоже что-то есть --> - SciFi(11.12.2017 15:25, ссылка)
        
        Спасибо! - Evgeny_CD(11.12.2017 15:30)
        
        +1. Если это код, работающий с "объектами в памяти", то выигрыш будет небольшой. Исключение - SIMD. Если это работа с железом - да, короткий asm кусок может быть сильно быстрее С. Но это совсем не переносимая оптимизация. - Evgeny_CD(11.12.2017 13:47)
        
        Я говорил о ситуациях, когда нужно успеть за определённое время. То есть времянка не жёсткая, но есть общее ограничение. Здесь сишный код не даёт гарантий (сменилась версия компилятора - и привет). Тут уж не до переносимости. Ну или при "смене SciFi(78 знак., 11.12.2017 14:02)
        
        В большей части моих проектов я согласен с таким подходов. Но был один, в котором была куча матричного матана и адских алгоритмов оптимизации. Вот там скорость была критична, хоть увеличение размера кода раза в 2 или даже в 3 никого бы не Evgeny_CD(121 знак., 11.12.2017 12:51 - 13:06)
        
        Это то же самое, просто тот "небольшой участок кода" чрезмерно распух :-) - SciFi(11.12.2017 12:52)
        
        Причем там и С++ код-то с трудом понимал его автор - аддский математик (впрочем, хорошо писавший код под GCC на Linux, мы его потом портировали в устройство), так что про asm оптимизацию там никто и не думал вообще :) - Evgeny_CD(11.12.2017 12:56)
        
        По мере выставления все более и более строгих констрейнов на плюшки С++ его код становился все быстрее и быстрее, но и мата от него становилось больше :) - Evgeny_CD(11.12.2017 12:58)
  - Для метрики не хватает прокладки между дисплеем и стулом. - misyachniy(11.12.2017 12:02)