|
|
|
Инлайновая функция |
|
|
|
Jul 5 2018, 15:19
|
Группа: Участник
Сообщений: 12
Регистрация: 3-09-17
Пользователь №: 99 108
|
inline нужен, например, для функций в прерываниях, чтобы не допускать разрастания стека (о скорости выполнения уже говорили).
использование inline ещё не говорит о том, что функция будет сто процентов инлайниться. Для принудительного инланинга необходимо использования директиву #pragma inline = forced
--------------------
|
|
|
|
|
Jul 5 2018, 19:49
|
Профессионал
Группа: Свой
Сообщений: 1 032
Регистрация: 13-03-08
Из: Маськва
Пользователь №: 35 877
|
Цитата(scifi @ Jul 5 2018, 17:59) инлайн - нестандартное расширение. Можно пользоваться языком, у которого ключевое слово "инлайн" прописано в стандарте. Цитата(scifi @ Jul 5 2018, 17:59) Но дело даже не в этом. Вот не могу себе представить, где это реально может понадобиться. Например, какой-то макросозаменитель, вычисление которого быстрее, чем перекладывание параметров в нужном порядке по регистрам. Да, скорее всего компилятор проявит интеллект и сам заинлайнит. А может и нет. Проще подсказать.
--------------------
Тут обсуждается творческий порыв, а не соответствие каким-либо стандартам ©
|
|
|
|
|
Jul 5 2018, 20:07
|
Гуру
Группа: Свой
Сообщений: 5 228
Регистрация: 3-07-08
Из: Омск
Пользователь №: 38 713
|
Цитата(scifi @ Jul 5 2018, 17:59) Но дело даже не в этом. Вот не могу себе представить, где это реально может понадобиться. Результат компиляции функции-макроса, часто порождает более оптимальный код, чем результат оптимизации даже хорошего компилятора - оптимизаторы пока не идеальны. Да и иногда полезно при отладке (без оптимизации) иметь обязательный инлайнинг. А inline в си к сожалению вещь опциональная - на усмотрение компилятора. По-крайней мере в IAR. А ещё бывает нужно в качестве аргумента передать несуществующее значение, которое внутри макроса, конкатенируясь, даст реальные переменные/константы. Такой финт с inline-функцией не провернёшь. А ещё бывает желательно проверять валидность аргументов функции. В обычной функции (или inline) можно сделать такую проверку только с порождением кода и работающую в run-time. В макросе можно сделать проверку в build-time, не порождающую лишнего кода.
|
|
|
|
|
Jul 6 2018, 03:48
|
Местный
Группа: Свой
Сообщений: 475
Регистрация: 14-04-05
Из: Москва
Пользователь №: 4 140
|
Начиная с C++11 в каждой новой спецификации добавляются всё новые возможности выполнения кода на этапе компиляции. Это сейчас модно, а не инлайны, с которыми компиляторы уже давным-давно научились сами разбираться. Попереключайте настройки оптимизатора и посмотрите результаты компиляции. Адептам секты пресвятого инлайна смотреть результат оптимизации с ключом Size на максимуме не рекомендую , чтобы при виде сплошного антиинлайна не возникли суицидалные мысли. Сейчас мэинстрим чтобы программа вообще не порождала run-time кода Модно написать программу на несколько страниц и получить пару ассемблерных команд. Даже соревнования проходят кто больше кода на этапе компиляции выполнит. И тут очередной такой ТС с давно уже неактуальным инлайном на белом коне въезжает. Совет ТС - если у вас есть место где не проходите по скорости, а иначе зачем гнаться за инлайном, то лучше перепишите этот кусок более оптимально наблюдая за результатом компиляции. Может даже с уходом в ASM. Но надеяться на инлайн не стоит. Даже если вы директиву принудительного инлайна поставите, компилятор может её проигнорировать. Не из вредности, а из-за продвинутости оптимизатора. Кстати, приёмов оптимизации в арсенале компилятора очень много, но почему-то только инлайн так волнует души неокрепших программистов Почему вас раскручивание циклов вообще не волнует, а?
|
|
|
|
|
Jul 6 2018, 07:27
|
Гуру
Группа: Свой
Сообщений: 5 228
Регистрация: 3-07-08
Из: Омск
Пользователь №: 38 713
|
Цитата(VladislavS @ Jul 6 2018, 06:48) Почему вас раскручивание циклов вообще не волнует, а? Это точно Мне здесь на форуме один товарищ недавно рассказывал и пытался убеждать, что копирование через memcpy() в любом случае быстрее, чем написать это копирование простым циклом на си. Сколько я ему не намекал, что оптимизирующий компилятор может и этот цикл и даже саму memcpy(!) раскрутить в несколько ассемблерных инструкций (в зависимости от размера пересылки, выравниваний и известности параметров пересылки на этапе компиляции), а может и то и другое заменить просто оптимальным циклом с копированием внутри - так и не убедил его. Он только обиделся. Он приводил в доказательство какие-то частные случаи, в определённых созданных им условиях. Так он и не понял, что при включении максимальной оптимизации и чем лучше и продвинутее компилятор, тем результат будет больше зависеть от реализуемого действия (алгоритма), а не от способа его реализации (цикл-ли, инлайн или даже memcpy). Так и ТС здесь - уверен что что-то зависит от того, с inline он напишет функцию или без. Так что как я неоднократно убеждался - понимание принципов работы оптимизаторов ускользает от основной массы программистов, сколько не описывай это в мануалах. Ну и в результирующий ассемблерный код тоже как видно мало кто смотрит и понимает его. Иначе бы даже без мануалов всё было понятно. PS: Кстати - вдогонку, в тему: Иногда возникает желание сказать компилятору (IAR в частности), чтобы он не inline-ил функцию. Так это сделать посложнее чем сказать inline. А вот сделать функцию жёстко "не inline" вне зависимости от работы оптимизатора - это имхо гораздо полезнее чем сделать её inline.
|
|
|
|
|
Jul 6 2018, 07:36
|
Гуру
Группа: Свой
Сообщений: 3 020
Регистрация: 7-02-07
Пользователь №: 25 136
|
Цитата(jcxz @ Jul 6 2018, 10:27) Мне здесь на форуме один товарищ недавно рассказывал и пытался убеждать, что копирование через memcpy() в любом случае быстрее, чем написать это копирование простым циклом на си. Сколько я ему не намекал, что оптимизирующий компилятор может и этот цикл и даже саму memcpy(!) раскрутить в несколько ассемблерных инструкций (в зависимости от размера пересылки, выравниваний и известности параметров пересылки на этапе компиляции), а может и то и другое заменить просто оптимальным циклом с копированием внутри - так и не убедил его. Он только обиделся. Он приводил в доказательство какие-то частные случаи, в определённых созданных им условиях. Был случай, когда хотелось, чтобы memcpy был маленький и медленный. Скорость не нужна, а байтов жалко. Библиотечный memcpy шибко умный, видимо. Ускоренный настолько, что весит сотни байт :-( Хоть заменяй своим. Цитата(jcxz @ Jul 6 2018, 10:27) PS: Кстати - вдогонку, в тему: Иногда возникает желание сказать компилятору (IAR в частности), чтобы он не inline-ил функцию. Так это сделать посложнее чем сказать inline. А вот сделать функцию жёстко "не inline" вне зависимости от работы оптимизатора - это имхо гораздо полезнее чем сделать её inline. Очевидно же: взять адрес функции, загнать его в указатель volatile, не? И вызывать через этот указатель для верности.
|
|
|
|
|
Jul 6 2018, 07:51
|
Гуру
Группа: Свой
Сообщений: 5 228
Регистрация: 3-07-08
Из: Омск
Пользователь №: 38 713
|
Цитата(scifi @ Jul 6 2018, 10:36) Был случай, когда хотелось, чтобы memcpy был маленький и медленный. Скорость не нужна, а байтов жалко. Библиотечный memcpy шибко умный, видимо. Ускоренный настолько, что весит сотни байт :-( Хоть заменяй своим. Когда хочется иметь определённый ассемблерный результат, вне зависимости от умности компилятора, то есть только один надёжный выход - ассемблер. И не нужно его бояться. Цитата(scifi @ Jul 6 2018, 10:36) Очевидно же: взять адрес функции, загнать его в указатель volatile, не? И вызывать через этот указатель для верности. Не уверен что это прокатит с любым компилятором. Да, указатель он создаст, и пожалуй даже поставит команду LDR Rx, указатель. Но кто дальше ему мешает просто вставить код функции? Ведь все условия volatile указателя он уже выполнил: создал его, и чтение его выполнил. PS: Про #pragma inline=never знаю и его сейчас и использую в IAR. Но это компиляторо-зависимо.
|
|
|
|
|
Jul 6 2018, 11:13
|
неотягощённый злом
Группа: Свой
Сообщений: 2 746
Регистрация: 31-01-08
Из: Санкт-Петербург
Пользователь №: 34 643
|
Цитата(jcxz @ Jul 6 2018, 10:51) А в IAR разве нет атрибутов наподобие gcc и keil? У меня написан compiler.h в котором все нюансы компиляторов запрятаны. Типа Код #if defined(__GNUC__) # define __is_always_inline __inline__ __attribute__((__always_inline__)) #endif А пользовательский код никаких специфических вещей компиляторов не использует - только свою прослойку. Код static __is_always_inline void foo(void) { // do something } ИМХО прагмы в коде последнее дело...
--------------------
“Будьте внимательны к своим мыслям - они начало поступков” (Лао-Цзы)
|
|
|
|
|
Jul 6 2018, 11:26
|
Местный
Группа: Свой
Сообщений: 475
Регистрация: 14-04-05
Из: Москва
Пользователь №: 4 140
|
Цитата(jcxz @ Jul 6 2018, 14:23) Но я не знаю другого способа явно указать IAR-у - инлайнить или нет. Не знаю с какой версии, но Цитата In extended language mode, the IAR C/C++ Compiler also supports a limited selection of GCC-style attributes. Use the __attribute__ ((attribute-list)) syntax for these attributes. The following attributes are supported in part or in whole. For more information, see the GCC documentation. ● alias ● aligned ● always_inline ● cmse_nonsecure_call ● cmse_nonsecure_entry ● constructor ● deprecated ● noinline ● noreturn ● packed ● pcs (for IAR type attributes used on functions) ● section ● target (for IAR object attributes used on functions) ● transparent_union ● unused ● used ● volatile ● weak
|
|
|
|
|
|
1 чел. читают эту тему (гостей: 1, скрытых пользователей: 0)
Пользователей: 0
|
|
|