caxapa.ru :: В части отсутствия глюков солидарен, но вот компилер всего так и не создан.

Evgeny_CD, Архитектор (11.12.2017 12:10, просмотров: 258) ответил SciFi на Две метрики: размер и скорость. Очевидно же! То, что код не должен глючить, кагбэ подразумевается :-)

В части отсутствия глюков солидарен, но вот компилер всего так и не создан. http://caxapa.ru/738001.html
http://caxapa.ru/726792.html
Чтобы вводить метрику, надо: 1. Кодовую базу - компилятора всего нет. 2. Разные варианты оптимизации - скорость, размер, гибрид 3. Сравнительное тестирование кода разных компилеров 4. Еще важный критерий - трудоемкость получение результата. В GCC, как мы знаем, грамотно навтыканные прагмы, грамотный подбор опций компиляци и LTO -> --> может творить чудеса - это если время проекта на исчерпается до завершения всего этого титанического труда.

Ответить

- Ну кагбэ были слухи, что некоторые компиляторостроители вставляют детектор дристонов, который выплёвывает гениальный код когда надо. Типа как дизельгейт. Но вообще придумали же какой-то 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)

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