I searched Stack Overflow for the pros/cons of function-like macros v. inline functions.
I found the following discussion: Pros and Cons of Different macro function / inline methods in C
...but it didn't answer my primary burning question.
Namely, what is the overhead in c of using a macro function (with variables, possibly other function calls) v. an inline function, in terms of memory usage and execution speed?
Are there any compiler-dependent differences in overhead? I have both icc and gcc at my disposal.
My code snippet I'm modularizing is:
double AttractiveTerm = pow(SigmaSquared/RadialDistanceSquared,3); double RepulsiveTerm = AttractiveTerm * AttractiveTerm; EnergyContribution += 4 * Epsilon * (RepulsiveTerm - AttractiveTerm);
My reason for turning it into an inline function/macro is so I can drop it into a c file and then conditionally compile other similar, but slightly different functions/macros.
e.g.:
double AttractiveTerm = pow(SigmaSquared/RadialDistanceSquared,3); double RepulsiveTerm = pow(SigmaSquared/RadialDistanceSquared,9); EnergyContribution += 4 * Epsilon * (RepulsiveTerm - AttractiveTerm);
(note the difference in the second line...)
This function is a central one to my code and gets called thousands of times per step in my program and my program performs millions of steps. Thus I want to have the LEAST overhead possible, hence why I'm wasting time worrying about the overhead of inlining v. transforming the code into a macro.
Based on the prior discussion I already realize other pros/cons (type independence and resulting errors from that) of macros... but what I want to know most, and don't currently know is the PERFORMANCE.
I know some of you C veterans will have some great insight for me!!
By declaring a function inline, you can direct GCC to integrate that function's code into the code for its callers.
Unless your "CPU meter" is pegged at 100%, inline functions probably won't make your system faster. (Even in CPU-bound systems, inline will help only when used within the bottleneck itself, and the bottleneck is typically in only a small percentage of the code.)
Inline functions are sometimes more useful than macros, as they are safe to use, but can also reduce function call overhead. The inline keyword is a request to the compiler, certain functions won't be inlined like: large functions. functions having too many conditional arguments.
Calling an inline function may or may not generate a function call, which typically incurs a very small amount of overhead. The exact situations under which an inline
function actually gets inlined vary depending on the compiler; most make a good-faith effort to inline small functions (at least when optimization is enabled), but there is no requirement that they do so (C99, §6.7.4):
Making a function an inline function suggests that calls to the function be as fast as possible. The extent to which such suggestions are effective is implementation-defined.
A macro is less likely to incur such overhead (though again, there is little to prevent a compiler from somehow doing something; the standard doesn't define what machine code programs must expand to, only the observable behavior of a compiled program).
Use whatever is cleaner. Profile. If it matters, do something different.
Also, what fizzer said; calls to pow (and division) are both typically more expensive than function-call overhead. Minimizing those is a good start:
double ratio = SigmaSquared/RadialDistanceSquared; double AttractiveTerm = ratio*ratio*ratio; EnergyContribution += 4 * Epsilon * AttractiveTerm * (AttractiveTerm - 1.0);
Is EnergyContribution
made up only of terms that look like this? If so, pull the 4 * Epsilon
out, and save two multiplies per iteration:
double ratio = SigmaSquared/RadialDistanceSquared; double AttractiveTerm = ratio*ratio*ratio; EnergyContribution += AttractiveTerm * (AttractiveTerm - 1.0); // later, once you've done all of those terms... EnergyContribution *= 4 * Epsilon;
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With