I'm considering making a macro that is 27 lines long with a 8 character name. It is all trigonometry stuff that I use over and over again within the same iteration.
I'm thinking of doing this in order to avoid writing a function to make my program run faster. Do you guys think this is a good idea?
What is your longest C++ macro
I would implement it as a function first. If you find it is a performance bottleneck then put it in a macro (or inline function, or __fastcall, etc).
Unless you are calling the function a lot of times per frame I doubt the function calling overhead will affect much. In general, macros in C++ should be avoided if possible.
Unless you are calling the function a lot of times per frame I doubt the function calling overhead will affect much. In general, macros in C++ should be avoided if possible.
Show us your macro.
I'm pretty sure you can turn it into an inline function instead. The compiler might even be smart enough to do that for you.
Edit: Dang, too slow.
I'm pretty sure you can turn it into an inline function instead. The compiler might even be smart enough to do that for you.
Edit: Dang, too slow.
I don't use macros in C++, because they can be a nightmare to debug and there is usually a better alternative.
I'm considering making a macro that is 27 lines long with a 8 character name. It is all trigonometry stuff that I use over and over again within the same iteration.
I'm thinking of doing this in order to avoid writing a function to make my program run faster. Do you guys think this is a good idea?
However fast you think your code is, someone has written it faster off the shelf...
This might backfire badly.
Calling a function can actually be faster than inlining the same code all over the place, because of the way instruction caches work on modern CPUs. You never know unless you profile; and, generally, unless your profiler is telling you that your function call itself is a serious bottleneck, it's best not to waste time on it.
Calling a function can actually be faster than inlining the same code all over the place, because of the way instruction caches work on modern CPUs. You never know unless you profile; and, generally, unless your profiler is telling you that your function call itself is a serious bottleneck, it's best not to waste time on it.
This might backfire badly.
Calling a function can actually be faster than inlining the same code all over the place, because of the way instruction caches work on modern CPUs. You never know unless you profile; and, generally, unless your profiler is telling you that your function call itself is a serious bottleneck, it's best not to waste time on it.
I'd be really interested in finding out more about this topic. Is there a good source online that you would recommend?
-Josh
ApochPIQ is the best approach from my point of view. Aggresive inlined function may fail to fit the code within instruction cache, compiler is quite clever on this thought.. The best initial approach, if your macro is extensively used within another function, is to create a function near your caller, and use it in a straight manner. Iniline function hint is most likely good to use on small code functions (that generate small amount of ASM code), or functions that are not used extensively within another caller, not a 27 lines behemoth, from my point of view. Of course that would require both profiling and see asm code generated from the macro in each case.
I'd be really interested in finding out more about this topic. Is there a good source online that you would recommend?Wikipedia ;)
Modern compilers actually treat [font="Courier New"]inline[/font] as a hint, not a demand.
http://msdn.microsof...y/z8y1yy88.aspx
The insertion (called inline expansion or inlining) occurs only if the compiler's cost/benefit analysis show it to be profitable. Inline expansion alleviates the function-call overhead at the potential cost of larger code size.[/quote]So if you feel that some code is too small + used too often to be placed into a function, you can just put it into an inline function -- If the compiler agrees with you, it will inline that code (i.e. the same as if you'd used the OP's macro approach), otherwise, it will compile it as a regular function. In either case, the inline function is superior to the macro, as it's more maintainable, readable, debuggable, etc...
Wikipedia ;)
[quote name='jjd' timestamp='1323741620' post='4893351']I'd be really interested in finding out more about this topic. Is there a good source online that you would recommend?
Modern compilers actually treat [font="Courier New"]inline[/font] as a hint, not a demand.
http://msdn.microsof...y/z8y1yy88.aspx
The insertion (called inline expansion or inlining) occurs only if the compiler's cost/benefit analysis show it to be profitable. Inline expansion alleviates the function-call overhead at the potential cost of larger code size.[/quote]So if you feel that some code is too small + used too often to be placed into a function, you can just put it into an inline function -- If the compiler agrees with you, it will inline that code (i.e. the same as if you'd used the OP's macro approach), otherwise, it will compile it as a regular function. In either case, the inline function is superior to the macro, as it's more maintainable, readable, debuggable, etc...
[/quote]
Sorry, I wasn't clear in my reply. I know the generic effect of the 'inline' keyword, i.e. that it's a hint etc., I'm actually more interested in the details of how instruction cache design determines when it is beneficial or not.
-Josh
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement