[jenya7 0]

я в main вызываю функции. но я хочу сократить время исполнения. вместо того чтоб тратить время на переход к функциям я могу заинлайнить их. правильно ли я мыслю?

[CrimsonPig 0]

я в main вызываю функции. но я хочу сократить время исполнения. вместо того чтоб тратить время на переход к функциям я могу заинлайнить их. правильно ли я мыслю?

 

в общем правильно.

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

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

Например, статические функции не члены классов он точно догадается сам заинлайнить (если сочтет нужным), он может вообще порвать функции на куски и эти куски заинлайнить по местам вызова в разных частях исходника..

Так что если сильно интересует оптимизация, то следует глядеть в ассемблерный листинг на выходе и пытаться понять, "могут ли мои шаловливые ручки сделать лучше ?". скорее всего, нет.

Есть, конечно, тяжелая артиллерия, типа __force_inline или как его там. Только необдуманное применение таких вещей может легко привести к противоположным результатам.

 

А ответ на вопрос "стало ли быстрее" могут дать только сравнительные тесты. В подобных случаях некоторые по началу "красивые" идеи ведут к негативным результатам по совсем неочевидным причинам.

Вот, например, кое-кто с помощью молотка и чьей-то матери заинлайнил все, что движется в надежде получить быстрый код и сократить время на вызов процедур. Код разбух и стал плохо ложиться на instruction cache.. Каков будет результат ?

 

 

 

 

 

 

 

 

[xvr 12]

Первое правило оптимизации - не делайте этого. Второе правило (в случае если вы уверены, что именно тут надо оптимизировать) - не делайте этого ... пока не получите численные подтверждения, а не только 'вашу уверенность'

 

[jenya7 0]

ну ладно не буду. положусь на -Ofast. :)

[CrimsonPig 0]

ну ладно не буду. положусь на -Ofast. :)

 

Ну, в пределах разумного можно и инлайнить мелкие функции, вреда от этого не будет, а компилятору легче..

Что-нибудь, типа такого:

 

inline uint32 Pow2(uint32 aPower) {assert(aPower < 32); return (1<<aPower);}

 

 

[xvr 12]

Главное оставить этот inline компилятору, а не пытаться влепить руками тело функции вместо ее вызова :)

Да и inline писать тоже не всегда обязательно - вменяемые компиляторы сами сделают inline там, где надо, напишите вы это слово или нет ;)

 

[CrimsonPig 0]

Главное оставить этот inline компилятору, а не пытаться влепить руками тело функции вместо ее вызова :)

Да и inline писать тоже не всегда обязательно - вменяемые компиляторы сами сделают inline там, где надо, напишите вы это слово или нет ;)

 

Ой, не факт...

 

//---- myheader.h
class CMyClass
{
public: 

 inline CMyClass();

 int m_Val;
};

CMyClass::CMyClass()
{
m_Val = 42;
}

//---- myheader.h end-----

 

Без явного указания inline программа не скомпилится.

 

[xvr 12]

Это другое дело, тут проблема будет не в inline, а в double definition.

Давайте пока не будем рассматривать влияние inline (а равно как и static) на видимость функций и собираемость программ. (Тут еще template'ы можно вспомнить :) )

 

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

 

[MK2 0]

Это другое дело, тут проблема будет не в inline, а в double definition.

Давайте пока не будем рассматривать влияние inline (а равно как и static) на видимость функций и собираемость программ. (Тут еще template'ы можно вспомнить :) )

 

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

Тогда как скажите объяснить iar что бы он заинлайнил эту ф-цию, но и оптимизацией не выкинул пустой цикл?!

void inline generation()      const
    {
  GPIO_PinOutToggle(gpioPortB, 13);

  for(uint16_t i = 0; i < 0x2; i++);

   GPIO_PinOutToggle(gpioPortB, 13);
    }

[CrimsonPig 0]

Тогда как скажите объяснить iar что бы он заинлайнил эту ф-цию, но и оптимизацией не выкинул пустой цикл?!

void inline generation()      const
    {
  GPIO_PinOutToggle(gpioPortB, 13);

  for(uint16_t i = 0; i < 0x2; i++);

   GPIO_PinOutToggle(gpioPortB, 13);
    }

 

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

1.1 на сколько тактов задержки благородный дон рассчитывает в цикле данной конструкции?

1.2 платформозависимые кунштюки обычно плохо ложатся на платформонезависимый код, поэтому используют платформозависимые решения, типа asm "nop"

 

2. читать книжки про спецификатор volatile.

3. по возможности сделать эту функцию static

4. inline это всего лишь рекомендация, которой не всегда можно следовать. Например, что будет, если попытаться взять адрес заинлайненой функции ?

 

[megajohn 3]

1.поэтому используют платформозависимые решения, типа asm "nop"

 

дык есть платформы, где такты периферии гораздо ниже тактов CPU, и что останется от авторской идеи - вооще вопрос.

Надо будет как-нибудь поэксперементировать на CM3

 

[CrimsonPig 0]

дык есть платформы, где такты периферии гораздо ниже тактов CPU, и что останется от авторской идеи - вооще вопрос.

Надо будет как-нибудь поэксперементировать на CM3

 

Ну пусть сделает пару холостых записей (или чтений) в какой-нибудь регистр. Я же говорил, что к платформозависимым заморочкам надо подходить с платформозависимыми инструментами :)

[MK2 0]

CrimsonPig

 

про volatile я и забыл...

static в данном случае никак не решал ситуацию.

данное простое действие не требует какой-либо сверх точности, поэтому цель была решить именно платформонезависимым кодом