operator efficiency
Premature optimization is the root of all evil. _ALL_ evil. Seriously, stop while you still can.
Agreed. Your choice of operators most likely will not affect performance AT ALL in the long run, since it probably won't be the bottleneck. Spend your time optimizing stuff that matters; and if you don't know which stuff matters, spend your time figuring out which stuff matters.
Quote:Original post by WashuQuote:Original post by silvermace
Hi,
You shouldn't be worried too much about this level of
optimization too much.
but, to answer your question, you'd probably want to keep the
number of redundant function calls to a minimum.
Here is how i would re-implement your system:
*** Source Snippet Removed ***
do you understand whats going on above ?
This is a bad idea. You have redefined the fundamental behavior of operator+ to be mutating. Instead of using operator+, you should be using operator +=.Quote:
dont be affraid to use the features of C++, when used
appropriatly and sensibly, performace (in comparison with other
OO languages) is not even an issue.
Yes, and with that in mind, always make sure that your operators behave as one would expect them to. operator+ should be non-mutating, for instance.
That was obviously a mistake, you're a mod, why didnt you fix it?!
I've checked. If you turn optimization, inline your operator+ and operator=, on MSVC6.0 you'll probably have same assembly ouput in both cases. There's no call to = and no call to +, it just adds vector components one by one and stores 'em in destination.
Quote:Original post by silvermaceDon't be silly. Mods and staff can't go about editing the intent of people's posts. That's your responsibility.
That was obviously a mistake, you're a mod, why didnt you fix it?!
Quote:Original post by Dmytryinline is only a suggestion. Stop using it, because the compiler does a better of determine what needs to be inlined than you will in 99% of cases - and it can still ignore you!
I've checked. If you turn optimization, inline your operator+ and operator=...
If you're absolutely sure you want your function inlined, you can use compiler-specific extensions like __forceinline, though I wouldn't recommended it lightly, for the same reasons.
Quote:Original post by OluseyiQuote:Original post by Dmytryinline is only a suggestion. Stop using it, because the compiler does a better of determine what needs to be inlined than you will in 99% of cases - and it can still ignore you!
I've checked. If you turn optimization, inline your operator+ and operator=...
Actually it might still be a good idea to use it. I though the same thing but a friends project (some heavy compression stuff) got some rather large speed ups though careful use of 'inline' (With the VS6 compiler).
Admittedly its probably highly compiler dependant, but my point is that its not a redundant keyword just yet.
Quote:Original post by OluseyiQuote:Original post by Dmytryinline is only a suggestion. Stop using it, because the compiler does a better of determine what needs to be inlined than you will in 99% of cases - and it can still ignore you!
I've checked. If you turn optimization, inline your operator+ and operator=...
If you're absolutely sure you want your function inlined, you can use compiler-specific extensions like __forceinline, though I wouldn't recommended it lightly, for the same reasons.
No, "for same reasons" you should not use __forceinline, and use inline instead. Why? Because, as you said, inline can be ignored if there's no need to inline. That is, inline is a hint, and __forceinline is not, so __forceinline can really hurt performance alot.
And, i don't want to blow size of my programs with inlining everything. Many compilers either inline too much or don't inline at all.
There's many common myths about compilers,2 most common is:
1: are so stupid , and can not optimize out a=b+c;
2: are so smart that can optimize everything without any hints, and that optimization hints from human is very bad for performance. Inline, for more-or-less smart compilers, it's only "hint" that can be ignored. And for stupid compilers... stupid compilers have 3 or less modes:
1:Not inline at all, ignore inline keyword
2:Inline only functions with inline keyword.
3:Inline everything they can.
and without using inline keyword you have only modes 1 and 3, and 3 works like you put __forceinline keyword anywhere you can.
Inline is needed mainly not because of call overhead, but because with inlining compiler can optimize more things, IMHO. And i know that vector a+b is nearly always better to be inlined, and there's no point in inlining matrix inverse.
To get optimal performance out of such operations you have to vectorize them. Look at a library such as Blitz++ or the C++ port of uBLAS (part of boost); they use expression templates to build loop-amoritized and vectorized calculations. This is difficult for an expert to design and code correctly. To maximize performance on modern hardware, you also must arrange your data appropriately. For an pentium II+, to take advantage of SIMDs (MMX and/or SSE); for instance it's common to have an array of structurs for points, but the CPU wants a structure of arrays (e.g. an array for x, another for y, another z).
inline has semantic meaning (no external linkage) beyond the optimization suggestion, you can and most likely should use it for operators such as those dicussed here (you must use it if you define the operators in a header outside of a class declaration (member function defintions inside a class declartion are automatically inline), otherwise the code is malformed). It's probably best left to compiler to decide whether or not to actually inline the object code (e.g. don't use __forceinline unless you really mean it).
To regurgitate, the C/C++ keyword inline is not about optimization, it's about correct code. The optimization hint is a compiler implementation after-thought.
And since it's not very clear from the above, if you put the operator defintions in a .cpp file (external linkage), it is very difficult for compilers to optimize them (inlining or any other optimizations). (MSVC 7.x is the only compiler that I know of that can even attempt to). So operators generally belong in headers, and should be inline code.
Quote:Original post by OluseyiQuote:Original post by Dmytryinline is only a suggestion. Stop using it, because the compiler does a better of determine what needs to be inlined than you will in 99% of cases - and it can still ignore you!
I've checked. If you turn optimization, inline your operator+ and operator=...
If you're absolutely sure you want your function inlined, you can use compiler-specific extensions like __forceinline, though I wouldn't recommended it lightly, for the same reasons.
inline has semantic meaning (no external linkage) beyond the optimization suggestion, you can and most likely should use it for operators such as those dicussed here (you must use it if you define the operators in a header outside of a class declaration (member function defintions inside a class declartion are automatically inline), otherwise the code is malformed). It's probably best left to compiler to decide whether or not to actually inline the object code (e.g. don't use __forceinline unless you really mean it).
To regurgitate, the C/C++ keyword inline is not about optimization, it's about correct code. The optimization hint is a compiler implementation after-thought.
And since it's not very clear from the above, if you put the operator defintions in a .cpp file (external linkage), it is very difficult for compilers to optimize them (inlining or any other optimizations). (MSVC 7.x is the only compiler that I know of that can even attempt to). So operators generally belong in headers, and should be inline code.
Quote:Original post by Dmytry
No, "for same reasons" you should not use __forceinline, and use inline instead. Why? Because, as you said, inline can be ignored if there's no need to inline. That is, inline is a hint, and __forceinline is not, so __forceinline can really hurt performance alot.
Sometimes, the profiler shows the optimizing compiler's wrong, and then you have to use __forceinline. The most recent example I've seen of this was some method in wxWindows' wxString.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
