It is not mentioned in the article that writing "inline" does not automatically make the function inline. It only gives C++ compiler a hint that it might be worth inlining. Compiler can inline function even if it has no inline keyword, and can not inline even when the function has the keyword, if it decides inlining would be inefficient.
Unusual speed boost: size matters
11–20 of 74 posts
Re: Unusual speed boost: size matters
#12looking on example 1, I wonder why don't languages like C++ or D or Go just add a "pure" keyword for functions that don't modify the global environment or their arguments? this will help the optimizers a lot I imagine. and yeah, I get it that there still could be roundabout side-effects, it's not Haskell, but the compiler could just trust the programmer that he knows what he's doing when he sticks the "pure" keyword…
LLVM/Clang already has a pass that can infer the 'readonly' attribute.
http://llvm.org/docs/LangRef.html#function-attributes
https://github.com/llvm-mirror/llvm/blob/master/lib/Transfor...
Re: Unusual speed boost: size matters
#13looking on example 1, I wonder why don't languages like C++ or D or Go just add a "pure" keyword for functions that don't modify the global environment or their arguments? this will help the optimizers a lot I imagine. and yeah, I get it that there still could be roundabout side-effects, it's not Haskell, but the compiler could just trust the programmer that he knows what he's doing when he sticks the "pure" keyword…
> looking on example 1, I wonder why don't languages like C++ or D or Go just add a "pure" keyword for functions that don't modify the global environment or their arguments?
The function in example 1 is modifying a member variable, and there is indeed a keyword that requires functions not to modify the class they operate on: const. It's very powerful, and by a long shot my favourite feature of C++.
That said, the function in question actually has to modify a member variable.
Re: Unusual speed boost: size matters
#14the updateCachedWidth example probably gives the wrong idea to a lot of folks. You would be just as well off making computeWidth const/pure/readonly/whatever The compiler can even detect if it modifies anything and mark it for you. In fact, better compilers will compute mod/ref information and know that m_cachedWidth is not touched over that call. However, LLVM's (which is what at least Apple is using) basic stateles…
What a fantastic catch. This is also one of Meyer's Effective C++ tips: always use const when applicable.
Re: Unusual speed boost: size matters
#15the updateCachedWidth example probably gives the wrong idea to a lot of folks. You would be just as well off making computeWidth const/pure/readonly/whatever The compiler can even detect if it modifies anything and mark it for you. In fact, better compilers will compute mod/ref information and know that m_cachedWidth is not touched over that call. However, LLVM's (which is what at least Apple is using) basic stateles…
What a fantastic catch. This is also one of Meyer's Effective C++ tips: always use const when applicable.
Wrong const. He's talking about the gcc function attribute extension, which most of the time is too strict, so recommending its general use isn't a great idea.
C++ const has no effect on optimization, since it can be casted away.
And being aware of aliasing issues is a good idea in general; nothing the compiler does can fix this in the general case (e.g. if computeWidth() is located in an external shared library it's basically impossible for the compiler to determine that it can't modify m_cachedWidth)
Re: Unusual speed boost: size matters
#16looking on example 1, I wonder why don't languages like C++ or D or Go just add a "pure" keyword for functions that don't modify the global environment or their arguments? this will help the optimizers a lot I imagine. and yeah, I get it that there still could be roundabout side-effects, it's not Haskell, but the compiler could just trust the programmer that he knows what he's doing when he sticks the "pure" keyword…
There is[1] a `pure` attribute in GCC extensions to C and C++:
int square (int) __attribute__ ((pure));
[1] http://gcc.gnu.org/onlinedocs/gcc/Function-Attributes.html
Re: Unusual speed boost: size matters
#17Or even better then double:
inline void updateCachedWidth() { m_cachedWidth = computeWidth() * deviceScaleFactor(); }
Ghee, was that line so hard to read ? No it's easier ! (Might have just been an example though.)
Re: Unusual speed boost: size matters
#18Earlier quoted context omitted.
What a fantastic catch. This is also one of Meyer's Effective C++ tips: always use const when applicable.
Wrong const. He's talking about the gcc function attribute extension, which most of the time is too strict, so recommending its general use isn't a great idea. C++ const has no effect on optimization, since it can be casted away. And being aware of aliasing issues is a good idea in general; nothing the compiler does can fix this in the general case (e.g. if computeWidth() is located in an external shared library it's…
> C++ const has no effect on optimization, since it can be casted away.
Modifying an object that has had its const-ness casted away is undefined behaviour.
Re: Unusual speed boost: size matters
#19the updateCachedWidth example probably gives the wrong idea to a lot of folks. You would be just as well off making computeWidth const/pure/readonly/whatever The compiler can even detect if it modifies anything and mark it for you. In fact, better compilers will compute mod/ref information and know that m_cachedWidth is not touched over that call. However, LLVM's (which is what at least Apple is using) basic stateles…
I agree with the 'make things const' part, but I would expect m_cachedWidth to be mutable. I'm too lazy to check that now, but if so, that would not help here.
Even if it is not, I still think this is an example of "how you should modify your code". Reason? Doing
temp = foo();
temp *= bar();
m_member = temp;
Re: Unusual speed boost: size matters
#20Earlier quoted context omitted.
Wrong const. He's talking about the gcc function attribute extension, which most of the time is too strict, so recommending its general use isn't a great idea. C++ const has no effect on optimization, since it can be casted away. And being aware of aliasing issues is a good idea in general; nothing the compiler does can fix this in the general case (e.g. if computeWidth() is located in an external shared library it's…
> C++ const has no effect on optimization, since it can be casted away. Modifying an object that has had its const-ness casted away is undefined behaviour.
Sorry, I should have been more specific.
C/C++ const has no effect on optimization, unless it's on a global/static object and the compiler can see the original declaration.
I'm not going to look it up in the C++ spec, but in C it's only undefined behavior if the original object was const, and it would make sense for C++ to be the same.