Здравствуйте !
Допустим, у нас есть такая функция, которую мы собираемся вызывать 
так много раз, что и не сосчитаешь 

Пробуем написать ее аналог, используя "дефайны"


Какой из этих двух вариантов (если конечно они не содержат ошибок) предпочтительней для использования ?
(первый в три раза медленнее второго, но второй как-то ненадежно выглядит )
Например, в нем используется выражение " ((_pus)->Length = _cbLen) * 0 "
Всегда ли его левый сомножитель будет "вычисляться" или, при некоторых условиях, может игнорироваться ?

  Мож под дебагом игнорируется директива __inline. 
  __inline однозначно предпочтительнее, так как там идет проверка типов на этапе компиляции и проч. Нужно попробовать дизассемблировать релизовый экзешник и сравнить код. Я думаю разницы не будет.

Попробовала запустить не из под среды.
Результат тот же: соотношение один к трем.
Сейчас попробую посмотреть в CPU-шке, правда я там себя не очень уверенно чувствую 

Выложи два варианта в виде exe в релиз сборке. Посмотрим на оптимизацию. 

ммм...насколько я знаю компилятор оставляет за собой право не инлайнить функцию по своему усмотрению даже тогда когда явно указан модификатор __inline...

Сейчас, только переброшу это безобразие в пустой проект.
Да, на всякий случай: я под Builder`ом. Все равно выкладывать ?

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

Но, Partizan, скорее всего прав. 

Хорошо, только мне надо чуть времени.

Ага... Причем, реально inline должен работать только с указателями на внешние объекты не имя собственных переменных и ничего не возвращая. Кто не совсем понимает почему пусть вспомнит какие функции компилятор делает inline по возможности без нашей просьбы. 


очень похоже, на недавний спор "что лучше указатель или ссылка". То, что написали в учебнике для создания первичных представлений - одно. То что следует применять в отдельном случае на практике - другое. define - 100% разменяет объем на скорость. Директива inline, да еще не к месту примененная так и останется директивой.

"ничего не возвращая" в смысле не может быть и функцией в том числе ?

P.S.
 Прикрепила файл.

Присоединённый файл ( Кол-во скачиваний: 4 )
 Inline_Test.rar 185,10 Kb

void... а фнкцией она само собой быть не может. Это же подстановка. Вот как только появляется хоть один атрибут функции это уже не inline... 

"Нда... Сказали мы с Петром Иванычем" (с) 

Либо у меня еще и в Delphi пробелы с образованием, либо C++ это совсем не Delphi  

Добавлено через 5 минут и 9 секунд
P.S.
 А как насчет произведения, о котором я спрашивала в топике ?
 Всегда ли будет вычисляться левая часть ?

насколько я понял вопрос такой: всегда ли будет происходить присваивание?  Да




т.е функция  inline int max(int a, int b) { return (a>b)?  a: b; } не будет инлайниться? не согласен 



Это сообщение отредактировал(а) mes - 23.7.2008, 20:49

  Мне тоже кажеться что должно работать. Возможно такое ограничение есть у одного из компиляторов. Насколько я помню есть ограничение на число машинных команд.

Я не знаю Delphi, и не знаю что Вам на это сказать. Я имел ввиду, что нужно применить процедуры - ничего не возвращающие функции 
void fn_foo();

Крайний левый операнд в тринарном выражении будет вычисляться всегда - он проверяется на "0". Если он ">0" то второй оператор, а иначе - третий. Если же Вы хотите узнать будет ли повторяться бессмысленное умножение на "0" то да, будет.


А баба яга - протиФФ.   Я рассказал когда inline будет 100% inline во всех компиляторах. Некоторые случаи возможны и в более сложных ситуациях. Зависит от "ума" компилятора, и того к чему он преобразует внутри "себя любимого". Но, например, вообще нереализуем рекурсивный inline вызов. Столкнулся пару месяцев назад - чужой проект был "глубоко оптимизирован" - перед каждой функцией стояло inline. Я с ним долбался долго, а потом дай-ка думаю посношу это... и... и нифига не изменилось, блин! Поспрашивал на electronix? там сказали почитай Саттера. Почитал - полный бред ниочем, мол может оптимизировать? а может и не оптимизировать, смотря от урожая травы в Африке  . И я блин вспомнил, читал де, что собственные закрытые функции класса компилер сам делает inline если они работают только с полями класса. Блин... Пришлось немного пошаманить, зато inline стали настоящими подстановками.

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

Добавлено @ 21:38

Нет, реально ограничение на целесообразность подстановки. И ее "пик" это отсутствие собственных переменных и возврата. Хоть в C а хоть в C++. Работайте с полями глобальной структуры или делайте закрытые методы обращающиеся по указателю к полям объекта - будет вам счастье. А иначе мрак хаоса описанный в книжонке Саттера...

Это сообщение отредактировал(а) DRUID3 - 23.7.2008, 21:45

Использовать define для этого точно не нужно, эта замена функции и в этом случае только усложнит сопровождение и отладку.
Хотя бы вот такой код, уже приведет к неправельным действиям :


Использование inline - это лишь подсказка компилятору о том, что эту функцию стоит сделать inline, и совершенно не факт, что он это сделает.



Каким профайлером производились замеры ?

Не поняла, почему и что имеется ввиду под nLength+1 ? Может аLength+1 ?
Это не страшно: изменим имя параметра.   
Меня больше волновало _Us_SetLength(pUnicodeString, pUnicodeString->Length + 1),
но вроде все нормально. 





Да простым QueryPerformanceCounter - ом

Лучше профайлером, тогда более менее точно станет понятно, на что именно больше всего тратится ресурсов.



Ну, тогда продолжайте использовать. Мое дело предупредить ^_^

  Дело не в имени, а в выражении. Насколько я знаю макрос может взять не все выражение, чтобы он взял все там нужно в выражении скобки поставить каждому параметру.

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

множиться будет всегда, но можно сделать и быстрее, если не умножать, а делать побитовый & с нулём.
поэтому,  при условии, что длИны - представляются целыми типами,  мой вариант таков:

_cbLen тут стоит запихать в скобочки, как сказал тов. Alexeis, но не обязательно.
В данном конкретном случае это не страшно: 

• сравнение вычисляется слева-направо
• сравнение имеет более низкий приоритет, чем сложение.

т.е. в предложенном случае, ваше оригинальное макро:

поведёт себя "хорошо", т.е х>y+z будет всегда идентично x>(y+z). 
НО, т.к. иногда действия с операндами, которые запихивают в макро дают нежелаемые результаты,  не засовывать "операнды" макро в скобочки - плохой вкус.

не стоит использовать define, нервные клетки не восстанавливаются...
Обычная функция делающая то-же самое будет не медленнее.
Компилятор в состоянии разобраться, в каком контексте вызывается функция, если она вызывается один раз, то встраивание ничего не даст кроме увеличения объема кода.
Если функция вызывается в цикле, то даст, и скорее всего она будет встроена. Так зачем брать на себя работу компилятора?

Это как???   "На глазок"?


 Нет, он не всегда, причем далеко не всегда в состоянии разобраться...

нет  


с тем примером в 2 строчки он пожалуй сможет разобраться.
вообще чем меньше функция, тем больше шансов что она будет заинлайнена, если функция большая и выполняется долго, то стоимость ее вызова, по сравнению с выполнением самой функциии незначительна и встраивать смысла нет...
Но все эти аспекты анализировать самостоятельно - занятие неблагодарное, так что лучше доверить это компилятору.
Плюс функции в том, что в одном случае она будет встроена, в другом нет. Если она вызывается из 100 разных мест, то реально встраивать нужно в одном - двух, там где она часто вызывается и стоимость вызова большая. В остальных случаях проще вызвать... Ну а макрос на 100% разменяет объем на скорость, при этом разницы в скорости не будет, так как там где нужно функция будет то-же встроена...

Вот выдержка из справки по билдеру


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

Первый
Нормальный компилятор должен сделать не медленнее
Рекомендую заменить это 'выражение' на (((_pus)->Length = (_cbLen)) , 0) Хотя нормальный компилятор сделает практически тоже самое

Проверил - сделал вызовы обоих версих функции, скормил все это Intel компилятору (на Linux) - код АБСОЛЮТНО одинаковый! (см атач)

Кроме того, у define'а есть еще один ОГРОМНЫЙ подводный камень:
Это нормально откомпилится и будет работать (С++ допускает функции с одинаковыми именами но разными параметрами). Если бы у вас был #define вместо первой функции - вы получили бы маловразумительные сообщения о массе ошибок на месте определения второй функции.


Присоединённый файл ( Кол-во скачиваний: 4 )
 tst.zip 1,35 Kb

а как?

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

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

Я же свои злоключения высказал, они могут пригодиЦЦо и другим идущим по этому пути.   

Вообще было бы очень клево, если бы кто-то не поленился, посидел с дизассемблером и несколькими компиляторами и накатал статейку "о том, как не надо применять inline"   

ЭТо кто вам такую ерунду сказал?1  


Ничего подобного. 100% на всех компиляторах - инлайна никогда не будет. Есть всякие форсирующие директивы, есть ключевое слово inline - хинт компилеру, есть оптимизатор.


Ничего подобного. Простые рекурсии (читай - рекурсии, которые были не в тему) - любой хороший комплер в состоянии развернуть.

а стек для чего?


вот xvr написал исчерпывающий пост, что еще нужно?
сидеть с дизассемблером не нужно, достаточно в release версии программы поставить брэйкпоинт в место вызова функции, например в цикле и когда он сработает клацнуть Show Disassembly, бегая отладчиком по рилиз версии, очень хорошо видно что и когда оптимизатор встраивает даже без дизассемблера, так как отладчик в заинлайненые функции не заходит. 

Effective C++, Глава 1:
Правило 1:

Суровая правда жизни  ...

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

А подстановкой мы что экономим!!!???  

угу... А еще надо хорошо учиться и слушать папу и маму...  

Пруфлинк?


 


При том, что развернув рекурсию в цикл, полученное можно заинлайнить.

Насчёт рекурсии - проверено на VC++ 2005, на VC++ 2008 тоже, думаю, сработает.

Исходный код:


Получаем:


Это сообщение отредактировал(а) Любитель - 24.7.2008, 17:44

я написал это не для того, чтобы пустые фразы ниже увидеть, а к тому, что если кому-то это интересно, то как минимум можно обратиться к материалу из книги, которую я указал для уточнения.


Это сообщение отредактировал(а) varnie - 24.7.2008, 18:21

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

C++ компилятор от борланда на столько крив и глючен, что не достоен называться компилятором.Он отстал от жизни лет на 20.
Возьмите как образец G++, компилятор от Intel или M$ VS.



Хвостовая рекурсия раскладывается в цикл элементарно. Такие оптимизации уже давно не редкость.


Это именно что ерунда. Сколько пользовался !нормальными! компиляторами никогда такого не замечал в релиз-сборках проектов.


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

"Ох, не легкая это работа - из болота тащить бегемота" (с) 
Спасибо всем тащившим  

P.S.
 Я много вынесла из этой ветки. 

Хоть уже и не актуально, но раз уж обещал дизассемблировать примеры, то в выложенном на первой странице exe компилятор действительно проигнорировал inline, на уровне маш. кода осуществялется вызов отдельной процедуры. 

Извиняюсь за задержку, запамятовал  

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




Спасибо большое. Теперь предположения, превратились в уверенность 



Это сообщение отредактировал(а) Riply - 26.7.2008, 22:39

Riply, а с каким компилятором ты вообще работаешь?

Это сообщение отредактировал(а) Supersedes - 29.7.2008, 12:36

В данном случае, все происходило под Builder`ом.

Кстати, о птичках - откомпилировал тест под Билдером (6.0)


Поставил режим 'Release', все заинлайнилось:

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

Можете себе представить какое мнение у меня сложилось о способностях Builder`а,
после того как он отказался инлайнить такую простую функцию.
Вам удалось чуть-чуть его (это мнение) поднять . Builder должен быть Вам благодарен 
P.S.
 И я тоже благодарна